Module: Mesa Branch: main Commit: eb96a4bffe295b91da813ac7af73250ce4bcd3e8 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=eb96a4bffe295b91da813ac7af73250ce4bcd3e8
Author: Eric Engestrom <e...@igalia.com> Date: Thu Jan 11 11:16:00 2024 +0000 docs: fix syntax highlighting on shell commands Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27010> --- docs/android.rst | 18 +++++++++--------- docs/application-issues.rst | 2 +- docs/ci/bare-metal.rst | 6 +++--- docs/ci/index.rst | 8 ++++---- docs/ci/local-traces.rst | 6 +++--- docs/codingstyle.rst | 2 +- docs/download.rst | 4 ++-- docs/drivers/asahi.rst | 4 ++-- docs/drivers/freedreno.rst | 30 +++++++++++++++--------------- docs/drivers/llvmpipe.rst | 6 +++--- docs/drivers/panfrost.rst | 6 +++--- docs/drivers/venus.rst | 12 ++++++------ docs/egl.rst | 2 +- docs/gallium-nine.rst | 4 ++-- docs/gpuvis.rst | 8 ++++---- docs/install.rst | 22 +++++++++++----------- docs/meson.rst | 32 ++++++++++++++++---------------- docs/osmesa.rst | 2 +- docs/perfetto.rst | 22 +++++++++++----------- docs/releasing.rst | 20 ++++++++++---------- docs/repository.rst | 20 ++++++++++---------- docs/shading.rst | 2 +- docs/submittingpatches.rst | 6 +++--- docs/xlibdriver.rst | 2 +- 24 files changed, 123 insertions(+), 123 deletions(-) diff --git a/docs/android.rst b/docs/android.rst index 4bdb8bcf6ea..c26d6cb3093 100644 --- a/docs/android.rst +++ b/docs/android.rst @@ -41,7 +41,7 @@ Then, create your Meson cross file to use it, something like this Now, use that cross file for your Android build directory (as in this one cross-compiling the turnip driver for a stock Pixel phone) -.. code-block:: console +.. code-block:: sh meson setup build-android-aarch64 \ --cross-file android-aarch64 \ @@ -61,7 +61,7 @@ read-only disk image on ``/vendor``. To be able to replace them for driver development, we need to unlock the device and remount ``/vendor`` read/write. -.. code-block:: console +.. code-block:: sh adb disable-verity adb reboot @@ -69,7 +69,7 @@ driver development, we need to unlock the device and remount Now you can replace drivers as in: -.. code-block:: console +.. code-block:: sh adb push build-android-aarch64/src/freedreno/vulkan/libvulkan_freedreno.so /vendor/lib64/hw/vulkan.sdm710.so @@ -91,7 +91,7 @@ using scp from outside the container. On your device, you'll want to make ``/`` read-write. ssh in as root and run: -.. code-block:: console +.. code-block:: sh crossystem dev_boot_signed_only=0 /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partitions 4 @@ -100,7 +100,7 @@ and run: Then, we'll switch Android from using an image for ``/vendor`` to using a bind-mount from a directory we control. -.. code-block:: console +.. code-block:: sh cd /opt/google/containers/android/ mkdir vendor-ro @@ -123,7 +123,7 @@ change it to:: Now, restart the UI to do a full reload: -.. code-block:: console +.. code-block:: sh restart ui @@ -136,7 +136,7 @@ then the ``mount`` command should show:: Now, replacing your DRI driver with a new one built for Android should be a matter of: -.. code-block:: console +.. code-block:: sh scp msm_dri.so $HOST:/opt/google/containers/android/vendor-rw/lib64/dri/ @@ -149,7 +149,7 @@ available to the NDK, assuming you're building anything but the Freedreno Vulkan driver for KGSL. You can mostly put things in place with: -.. code-block:: console +.. code-block:: sh scp $HOST:/opt/google/containers/android/vendor-rw/lib64/libdrm.so \ NDKDIR/sysroot/usr/lib/aarch64-linux-android/lib/ @@ -166,6 +166,6 @@ find you need to reload the whole Android container. To do so without having to log in to Chrome again every time, you can just kill the container and let it restart: -.. code-block:: console +.. code-block:: sh kill $(cat /run/containers/android-run_oci/container.pid ) diff --git a/docs/application-issues.rst b/docs/application-issues.rst index 3fba2d1a864..27fdadcb424 100644 --- a/docs/application-issues.rst +++ b/docs/application-issues.rst @@ -35,7 +35,7 @@ than the given year. For example, if the game was released in 2001, do -.. code-block:: console +.. code-block:: sh export MESA_EXTENSION_MAX_YEAR=2001 diff --git a/docs/ci/bare-metal.rst b/docs/ci/bare-metal.rst index 2b3db32643f..b9d5f654f7f 100644 --- a/docs/ci/bare-metal.rst +++ b/docs/ci/bare-metal.rst @@ -138,7 +138,7 @@ Setup Each board will be registered in freedesktop.org GitLab. You'll want something like this to register a fastboot board: -.. code-block:: console +.. code-block:: sh sudo gitlab-runner register \ --url https://gitlab.freedesktop.org \ @@ -194,7 +194,7 @@ Caching downloads To improve the runtime for downloading traces during traces job runs, you will want a pass-through HTTP cache. On your runner box, install nginx: -.. code-block:: console +.. code-block:: sh sudo apt install nginx libnginx-mod-http-lua @@ -213,7 +213,7 @@ your devices are on. Enable the site and restart nginx: -.. code-block:: console +.. code-block:: sh sudo rm /etc/nginx/sites-enabled/default sudo ln -s /etc/nginx/sites-available/fdo-cache /etc/nginx/sites-enabled/fdo-cache diff --git a/docs/ci/index.rst b/docs/ci/index.rst index f085785886f..fe8c214e9ee 100644 --- a/docs/ci/index.rst +++ b/docs/ci/index.rst @@ -64,13 +64,13 @@ Farm management When the farm starts failing for any reason (power, network, out-of-space), it needs to be disabled by pushing separate MR with -.. code-block:: console +.. code-block:: sh git mv .ci-farms{,-disabled}/$farm_name After farm restore functionality can be enabled by pushing a new merge request, which contains -.. code-block:: console +.. code-block:: sh git mv .ci-farms{-disabled,}/$farm_name @@ -279,7 +279,7 @@ command`` instead of ``run -it $IMAGE bash`` (which you may also find useful for debug). Extract your build setup variables from .gitlab-ci.yml and run the CI meson build script: -.. code-block:: console +.. code-block:: sh IMAGE=registry.freedesktop.org/anholt/mesa/debian/android_build:2020-09-11 sudo docker pull $IMAGE @@ -288,7 +288,7 @@ useful for debug). Extract your build setup variables from All you have left over from the build is its output, and a _build directory. You can hack on mesa and iterate testing the build with: -.. code-block:: console +.. code-block:: sh sudo docker run --rm -v `pwd`:/mesa $IMAGE meson compile -C /mesa/_build diff --git a/docs/ci/local-traces.rst b/docs/ci/local-traces.rst index ced5457e360..a834c8ac4f0 100644 --- a/docs/ci/local-traces.rst +++ b/docs/ci/local-traces.rst @@ -12,7 +12,7 @@ Running single trace -------------------- A simple run to see the output of the trace can be done with -.. code-block:: console +.. code-block:: sh apitrace replay -w name_of_trace.trace @@ -20,7 +20,7 @@ For more information, look into the `Apitrace documentation <https://github.com/ For comparing checksums use: -.. code-block:: console +.. code-block:: sh cd piglit/replayer export PIGLIT_SOURCE_DIR="../" @@ -34,7 +34,7 @@ Sometimes it's useful to be able to test traces on your local machine instead of Download the YAML file from your driver's ``ci/`` directory and then change the path in the YAML file from local proxy or MinIO to the local directory (url-like format ``file://``) -.. code-block:: console +.. code-block:: sh # The PIGLIT_REPLAY_DEVICE_NAME has to match name in the YAML file. export PIGLIT_REPLAY_DEVICE_NAME='your_device_name' diff --git a/docs/codingstyle.rst b/docs/codingstyle.rst index cf4d4ba9fd0..f595d887b04 100644 --- a/docs/codingstyle.rst +++ b/docs/codingstyle.rst @@ -126,7 +126,7 @@ Basic formatting guidelines - This GNU indent command generally does the right thing for formatting: - .. code-block:: console + .. code-block:: sh indent -br -i3 -npcs --no-tabs infile.c -o outfile.c diff --git a/docs/download.rst b/docs/download.rst index 5eb3e73e853..d8e994963b0 100644 --- a/docs/download.rst +++ b/docs/download.rst @@ -28,13 +28,13 @@ Mesa releases are available in two formats: ``.tar.xz`` and ``.tar.gz``. To unpack the tarball: -.. code-block:: console +.. code-block:: sh tar xf mesa-Y.N.P.tar.xz or -.. code-block:: console +.. code-block:: sh tar xf mesa-Y.N.P.tar.gz diff --git a/docs/drivers/asahi.rst b/docs/drivers/asahi.rst index 9402afbc277..32a8867df6d 100644 --- a/docs/drivers/asahi.rst +++ b/docs/drivers/asahi.rst @@ -307,14 +307,14 @@ useful for exercising the compiler. To build, use options: Then run an OpenGL workload with environment variable: -.. code-block:: console +.. code-block:: sh LD_PRELOAD=~/mesa/build/src/asahi/drm-shim/libasahi_noop_drm_shim.so For example to compile a shader with shaderdb and print some statistics along with the IR: -.. code-block:: console +.. code-block:: sh ~/shader-db$ AGX_MESA_DEBUG=shaders,shaderdb ASAHI_MESA_DEBUG=precompile LIBGL_DRIVERS_PATH=~/lib/dri/ LD_PRELOAD=~/mesa/build/src/asahi/drm-shim/libasahi_noop_drm_shim.so ./run shaders/glmark/1-12.shader_test diff --git a/docs/drivers/freedreno.rst b/docs/drivers/freedreno.rst index fd46cbd59d0..422864a3a46 100644 --- a/docs/drivers/freedreno.rst +++ b/docs/drivers/freedreno.rst @@ -346,7 +346,7 @@ though going here is the last resort and likely won't be helpful. The ``PC`` value is an instruction address in the current firmware. You would need to disassemble the firmware (/lib/firmware/qcom/aXXX_sqe.fw) via: -.. code-block:: console +.. code-block:: sh afuc-disasm -v a650_sqe.fw > a650_sqe.fw.disasm @@ -373,14 +373,14 @@ send to the kernel. Mesa itself doesn't implement a way to stream them out (though it maybe should!). Instead, we have an interface for the kernel to capture all submitted command streams: -.. code-block:: console +.. code-block:: sh cat /sys/kernel/debug/dri/0/rd > cmdstream & By default, command stream capture does not capture texture/vertex/etc. data. You can enable capturing all the BOs with: -.. code-block:: console +.. code-block:: sh echo Y > /sys/module/msm/parameters/rd_full @@ -400,7 +400,7 @@ Additionally it is geared towards analyzing the GPU state at the moment of the c Alternatively, it's possible to obtain the whole submission with all command streams via ``/sys/kernel/debug/dri/0/hangrd``: -.. code-block:: console +.. code-block:: sh sudo cat /sys/kernel/debug/dri/0/hangrd > logfile.rd // Do the cat _before_ the expected hang @@ -421,17 +421,17 @@ Dumping rendering results or even just memory is currently unsupported. Replaying is done via `replay` tool: -.. code-block:: console +.. code-block:: sh ./replay test_replay.rd More examples: -.. code-block:: console +.. code-block:: sh ./replay --first=start_submit_n --last=last_submit_n test_replay.rd -.. code-block:: console +.. code-block:: sh ./replay --override=0 --generator=./generate_rd test_replay.rd @@ -453,7 +453,7 @@ The workflow would look like this: 1. Find the cmdstream № you want to edit; 2. Decompile it: -.. code-block:: console +.. code-block:: sh ./rddecompiler -s %cmd_stream_n% example.rd > generate_rd.c @@ -461,7 +461,7 @@ The workflow would look like this: 4. Compile it back, see rdcompiler-meson.build for the instructions; 5. Plug the generator into cmdstream replay: -.. code-block:: console +.. code-block:: sh ./replay --override=%cmd_stream_№% --generator=~/generate_rd @@ -529,7 +529,7 @@ because it would require much less breadcrumb writes and syncs. Breadcrumbs settings: -.. code-block:: console +.. code-block:: sh TU_BREADCRUMBS=%IP%:%PORT%,break=%BREAKPOINT%:%BREAKPOINT_HITS% @@ -544,26 +544,26 @@ A typical work flow would be: - Start listening for breadcrumbs on a remote host: -.. code-block:: console +.. code-block:: sh nc -lvup $PORT | stdbuf -o0 xxd -pc -c 4 | awk -Wposix '{printf("%u:%u\n", "0x" $0, a[$0]++)}' - Start capturing command stream; - Replay the hanging trace with: -.. code-block:: console +.. code-block:: sh TU_BREADCRUMBS=$IP:$PORT,break=-1:0 - Increase hangcheck period: -.. code-block:: console +.. code-block:: sh echo -n 60000 > /sys/kernel/debug/dri/0/hangcheck_period_ms - After GPU hang note the last breadcrumb and relaunch trace with: -.. code-block:: console +.. code-block:: sh TU_BREADCRUMBS=%IP%:%PORT%,break=%LAST_BREADCRUMB%:%HITS% @@ -589,7 +589,7 @@ Finding instances of stale reg reads Turnip has a debug option to stomp the registers with invalid values to catch the cases where stale data is read. -.. code-block:: console +.. code-block:: sh MESA_VK_ABORT_ON_DEVICE_LOSS=1 \ TU_DEBUG_STALE_REGS_RANGE=0x00000c00,0x0000be01 \ diff --git a/docs/drivers/llvmpipe.rst b/docs/drivers/llvmpipe.rst index bad2953b0b0..db45f9f2531 100644 --- a/docs/drivers/llvmpipe.rst +++ b/docs/drivers/llvmpipe.rst @@ -31,7 +31,7 @@ Requirements For Linux, on a recent Debian based distribution do: - .. code-block:: console + .. code-block:: sh aptitude install llvm-dev @@ -42,7 +42,7 @@ Requirements For a RPM-based distribution do: - .. code-block:: console + .. code-block:: sh yum install llvm-devel @@ -76,7 +76,7 @@ Building To build everything on Linux invoke meson as: -.. code-block:: console +.. code-block:: sh mkdir build cd build diff --git a/docs/drivers/panfrost.rst b/docs/drivers/panfrost.rst index b30a0b3ce2c..83b12d429d2 100644 --- a/docs/drivers/panfrost.rst +++ b/docs/drivers/panfrost.rst @@ -118,7 +118,7 @@ Additional GPU IDs are enumerated in the ``panfrost_model_list`` list in As an example: assuming Mesa is installed to a local path ``~/lib`` and Mesa's build directory is ``~/mesa/build``, a shader can be compiled for Mali-G52 as: -.. code-block:: console +.. code-block:: sh ~/shader-db$ BIFROST_MESA_DEBUG=shaders \ LIBGL_DRIVERS_PATH=~/lib/dri/ \ @@ -128,7 +128,7 @@ build directory is ``~/mesa/build``, a shader can be compiled for Mali-G52 as: The same shader can be compiled for Mali-T720 as: -.. code-block:: console +.. code-block:: sh ~/shader-db$ MIDGARD_MESA_DEBUG=shaders \ LIBGL_DRIVERS_PATH=~/lib/dri/ \ @@ -148,7 +148,7 @@ and various flags to dEQP mimic the surfaceless environment that our continuous integration (CI) uses. This eliminates window system dependencies, although it requires a specially built CTS: -.. code-block:: console +.. code-block:: sh ~/VK-GL-CTS/build/external/openglcts/modules$ PAN_MESA_DEBUG=trace,dump \ LIBGL_DRIVERS_PATH=~/lib/dri/ \ diff --git a/docs/drivers/venus.rst b/docs/drivers/venus.rst index f042d2f6f88..1c36ea35ef7 100644 --- a/docs/drivers/venus.rst +++ b/docs/drivers/venus.rst @@ -51,7 +51,7 @@ vtest The simplest way to test Venus is to use virglrenderer's vtest server. To build virglrenderer with Venus support and to start the vtest server, -.. code-block:: console +.. code-block:: sh $ git clone https://gitlab.freedesktop.org/virgl/virglrenderer.git $ cd virglrenderer @@ -63,7 +63,7 @@ build virglrenderer with Venus support and to start the vtest server, In another shell, -.. code-block:: console +.. code-block:: sh $ export VK_ICD_FILENAMES=<path-to-virtio_icd.x86_64.json> $ export VN_DEBUG=vtest @@ -84,7 +84,7 @@ driver, which was upstreamed in kernel 5.16. crosvm is written in Rust. To build crosvm, make sure Rust has been installed and -.. code-block:: console +.. code-block:: sh $ git clone --recurse-submodules \ https://chromium.googlesource.com/chromiumos/platform/crosvm @@ -97,7 +97,7 @@ Note that crosvm must be built with ``default-no-sandbox`` or started with This is how one might want to start crosvm -.. code-block:: console +.. code-block:: sh $ sudo LD_LIBRARY_PATH=<...> VK_ICD_FILENAMES=<...> ./target/debug/crosvm run \ --gpu vulkan=true \ @@ -126,7 +126,7 @@ the `Chrome OS kernel To build minigbm and to enable minigbm support in virglrenderer, -.. code-block:: console +.. code-block:: sh $ git clone https://chromium.googlesource.com/chromiumos/platform/minigbm $ cd minigbm @@ -141,7 +141,7 @@ Make sure a host Wayland compositor is running. Replace In the guest, build and start sommelier, the special Wayland compositor, -.. code-block:: console +.. code-block:: sh $ git clone https://chromium.googlesource.com/chromiumos/platform2 $ cd platform2/vm_tools/sommelier diff --git a/docs/egl.rst b/docs/egl.rst index 9d17ca266ae..95a96959816 100644 --- a/docs/egl.rst +++ b/docs/egl.rst @@ -18,7 +18,7 @@ Build EGL #. Configure your build with the desired client APIs and enable the driver for your hardware. For example: - .. code-block:: console + .. code-block:: sh $ meson configure \ -D egl=enabled \ diff --git a/docs/gallium-nine.rst b/docs/gallium-nine.rst index 3cbfc23d283..6351fcaf44d 100644 --- a/docs/gallium-nine.rst +++ b/docs/gallium-nine.rst @@ -20,7 +20,7 @@ Build Beware: Most Direct3D games are 32-bit, and thus need a 32-bit version of Mesa. -.. code-block:: console +.. code-block:: sh $ meson configure \ -D gallium-nine=true \ @@ -43,6 +43,6 @@ Run Before running your application in Wine, verify that everything works as expected by running: -.. code-block:: console +.. code-block:: sh $ wine ninewinecfg diff --git a/docs/gpuvis.rst b/docs/gpuvis.rst index 0d240c784b8..df3922fb4fb 100644 --- a/docs/gpuvis.rst +++ b/docs/gpuvis.rst @@ -14,7 +14,7 @@ Any traces can be made with trace-cmd. The Gpuvis repository contains `scripts <https://github.com/mikesart/gpuvis/tree/master/sample>`__ for configuring the markers needed for GPU events. To start tracing: -.. code-block:: console +.. code-block:: sh sh trace-cmd-setup.sh && sh trace-cmd-start-tracing.sh # Start your game etc. Then to capture a trace @@ -30,7 +30,7 @@ Run on Steamos Steamos includes a script (`gpu-trace <https://github.com/lostgoat/gpu-trace>`__) to capture traces. -.. code-block:: console +.. code-block:: sh sudo gpu-trace # Press Ctrl+C to stop capture and open report in gpuvis @@ -39,7 +39,7 @@ Note that on Steamos gpuvis is actually not installed by default, but the script does write a gpu-trace.zip file in the current working directory. To open it you'll want to do the following on your development machine: -.. code-block:: console +.. code-block:: sh scp sd-host:gpu-trace.zip ./ unzip gpu-trace.zip @@ -60,7 +60,7 @@ PRESSURE_VESSEL_DEVEL=1 to set up the tracing filesystem so the trace marker can be written. This can e.g. be done by going to the game properties in Steam and setting the command line to -.. code-block:: console +.. code-block:: sh PRESSURE_VESSEL_DEVEL=1 %command% diff --git a/docs/install.rst b/docs/install.rst index dfa62ab38c7..03d903a12a3 100644 --- a/docs/install.rst +++ b/docs/install.rst @@ -46,7 +46,7 @@ Third party/extra tools. respectively, (or later) should work. On Windows with MinGW, install Flex and Bison with: - .. code-block:: console + .. code-block:: sh mingw-get install msys-flex msys-bison @@ -68,7 +68,7 @@ configure error message. Here are some common ways to retrieve most/all of the dependencies based on the packaging tool used by your distro. -.. code-block:: console +.. code-block:: sh zypper source-install --build-deps-only Mesa # openSUSE/SLED/SLES yum-builddep mesa # yum Fedora, OpenSuse(?) @@ -84,7 +84,7 @@ for \*nix systems like Linux and BSD, macOS, Haiku, and Windows. The general approach is: -.. code-block:: console +.. code-block:: sh meson setup builddir/ meson compile -C builddir/ @@ -92,7 +92,7 @@ The general approach is: On Windows you can also use the Visual Studio backend -.. code-block:: console +.. code-block:: sh meson setup builddir --backend=vs cd builddir @@ -108,7 +108,7 @@ It's often necessary or useful when debugging driver issues or testing new branches to run against a local build of Mesa without doing a system-wide install. Meson has built-in support for this with its ``devenv`` subcommand: -.. code-block:: console +.. code-block:: sh meson devenv -C builddir glxinfo @@ -126,7 +126,7 @@ assume ``$MESA_INSTALLDIR`` is an absolute path to this location. First, configure Mesa and install in the temporary location: -.. code-block:: console +.. code-block:: sh meson setup builddir/ -Dprefix="$MESA_INSTALLDIR" OTHER_OPTIONS meson install -C builddir/ @@ -135,7 +135,7 @@ where ``OTHER_OPTIONS`` is replaced by any meson configuration options you may want. For instance, if you want to build the LLVMpipe drivers, it would look like this: -.. code-block:: console +.. code-block:: sh meson setup builddir/ -Dprefix="$MESA_INSTALLDIR" \ -Dgallium-drivers=swrast -Dvulkan-drivers=swrast @@ -148,7 +148,7 @@ Which variable you have to set depends on the API. OpenGL ~~~~~~ -.. code-block:: console +.. code-block:: sh LD_LIBRARY_PATH="$MESA_INSTALLDIR/lib64" glxinfo @@ -159,7 +159,7 @@ contains ``libGL.so`` and use that one. Vulkan ~~~~~~ -.. code-block:: console +.. code-block:: sh VK_ICD_FILENAMES="$MESA_INSTALLDIR/share/vulkan/icd/my_icd.json" vulkaninfo @@ -170,7 +170,7 @@ is named ``lvp_icd.x86_64.json``. OpenCL ~~~~~~ -.. code-block:: console +.. code-block:: sh OCL_ICD_VENDORS="$MESA_INSTALLDIR/etc/OpenCL/vendors" clinfo @@ -247,6 +247,6 @@ determine the proper compiler and linker flags. For example, compiling and linking a GLUT application can be done with: -.. code-block:: console +.. code-block:: sh gcc `pkg-config --cflags --libs glut` mydemo.c -o mydemo diff --git a/docs/meson.rst b/docs/meson.rst index 181252bf86e..3fddc77974f 100644 --- a/docs/meson.rst +++ b/docs/meson.rst @@ -25,13 +25,13 @@ Unix-like OSes If Meson is not already installed on your system, you can typically install it with your package installer. For example: -.. code-block:: console +.. code-block:: sh sudo apt-get install meson # Ubuntu or -.. code-block:: console +.. code-block:: sh sudo dnf install meson # Fedora @@ -51,20 +51,20 @@ modules (Mako). You also need pkg-config (a hard dependency of Meson), Flex, and Bison. The easiest way to install everything you need is with `Chocolatey <https://chocolatey.org/>`__. -.. code-block:: console +.. code-block:: sh choco install python3 winflexbison pkgconfiglite You can even use Chocolatey to install MinGW and Ninja (Ninja can be used with MSVC as well) -.. code-block:: console +.. code-block:: sh choco install ninja mingw Then install Meson using pip -.. code-block:: console +.. code-block:: sh py -3 -m pip install meson packaging mako @@ -87,7 +87,7 @@ for each configuration you might want to use. Basic configuration is done with: -.. code-block:: console +.. code-block:: sh meson setup build/ @@ -98,7 +98,7 @@ build options at the end. To review the options which Meson chose, run: -.. code-block:: console +.. code-block:: sh meson configure build/ @@ -112,7 +112,7 @@ With additional arguments ``meson configure`` can be used to change options for a previously configured build directory. All options passed to this command are in the form ``-D "option"="value"``. For example: -.. code-block:: console +.. code-block:: sh meson configure build/ -Dprefix=/tmp/install -Dglx=true @@ -125,7 +125,7 @@ an empty list (``-D platforms=[]``). Once you've run the initial ``meson`` command successfully you can use your configured backend to build the project in your build directory: -.. code-block:: console +.. code-block:: sh ninja -C build/ @@ -133,7 +133,7 @@ The next step is to install the Mesa libraries, drivers, etc. This also finishes up some final steps of the build process (such as creating symbolic links for drivers). To install: -.. code-block:: console +.. code-block:: sh ninja -C build/ install @@ -168,7 +168,7 @@ Developers will often want to install Mesa to a testing directory rather than the system library directory. This can be done with the --prefix option. For example: -.. code-block:: console +.. code-block:: sh meson --prefix="${PWD}/build/install" build/ @@ -191,7 +191,7 @@ they are guaranteed to persist across rebuilds and reconfigurations. This example sets -fmax-errors for compiling C sources and -DMAGIC=123 for C++ sources: -.. code-block:: console +.. code-block:: sh meson setup builddir/ -Dc_args=-fmax-errors=10 -Dcpp_args=-DMAGIC=123 @@ -206,7 +206,7 @@ a new build dir for a different compiler. This is an example of specifying the Clang compilers and cleaning the build directory before reconfiguring with an extra C option: -.. code-block:: console +.. code-block:: sh CC=clang CXX=clang++ meson setup build-clang ninja -C build-clang @@ -230,7 +230,7 @@ CMake finder it will only find static libraries, it will never find which points to the root of an alternative installation (the prefix). For example: -.. code-block:: console +.. code-block:: sh meson setup builddir -Dcmake_module_path=/home/user/mycmake/prefix @@ -248,7 +248,7 @@ to find llvm-config: Then configure Meson: -.. code-block:: console +.. code-block:: sh meson setup builddir/ --native-file custom-llvm.ini @@ -268,7 +268,7 @@ Obviously, only CMake or llvm-config is required. Then configure Meson: -.. code-block:: console +.. code-block:: sh meson setup builddir/ --cross-file cross-llvm.ini diff --git a/docs/osmesa.rst b/docs/osmesa.rst index 282300510c3..af3321454f4 100644 --- a/docs/osmesa.rst +++ b/docs/osmesa.rst @@ -23,7 +23,7 @@ Building OSMesa Configure and build Mesa with something like: -.. code-block:: console +.. code-block:: sh meson setup builddir -Dosmesa=true -Dgallium-drivers=swrast -Dvulkan-drivers=[] -Dprefix=$PWD/builddir/install meson install -C builddir diff --git a/docs/perfetto.rst b/docs/perfetto.rst index a94f5decbd2..0d2eafa2f47 100644 --- a/docs/perfetto.rst +++ b/docs/perfetto.rst @@ -61,7 +61,7 @@ To capture a trace with Perfetto you need to take the following steps: `convenience script <https://perfetto.dev/docs/quickstart/linux-tracing#capturing-a-trace>`__ to start the tracing service: - .. code-block:: console + .. code-block:: sh cd subprojects/perfetto CONFIG=<path/to/gpu.cfg> OUT=out/linux_clang_release ./tools/tmux -n @@ -83,7 +83,7 @@ To capture a trace with Perfetto you need to take the following steps: To be a bit more explicit, here is a listing of commands reproducing the steps above : -.. code-block:: console +.. code-block:: sh # Configure Mesa with perfetto mesa $ meson . build -Dperfetto=true -Dvulkan-drivers=intel,broadcom -Dgallium-drivers= @@ -124,7 +124,7 @@ actually collecting traces. This can be achieved by setting the :envvar:`MESA_GPU_TRACES` environment variable before starting a Vulkan application : -.. code-block:: console +.. code-block:: sh MESA_GPU_TRACES=perfetto ./build/my_vulkan_app @@ -139,7 +139,7 @@ Freedreno / Turnip The Freedreno PPS driver needs root access to read system-wide performance counters, so you can simply run it with sudo: -.. code-block:: console +.. code-block:: sh sudo ./build/src/tool/pps/pps-producer @@ -150,13 +150,13 @@ The Intel PPS driver needs root access to read system-wide `RenderBasic <https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2023-0/gpu-metrics-reference.html>`__ performance counters, so you can simply run it with sudo: -.. code-block:: console +.. code-block:: sh sudo ./build/src/tool/pps/pps-producer Another option to enable access wide data without root permissions would be running the following: -.. code-block:: console +.. code-block:: sh sudo sysctl dev.i915.perf_stream_paranoid=0 @@ -165,7 +165,7 @@ Alternatively using the ``CAP_PERFMON`` permission on the binary should work too A particular metric set can also be selected to capture a different set of HW counters : -.. code-block:: console +.. code-block:: sh INTEL_PERFETTO_METRIC_SET=RasterizerAndPixelBackend ./build/src/tool/pps/pps-producer @@ -173,7 +173,7 @@ Vulkan applications can also be instrumented to be Perfetto producers. To enable this for given application, set the environment variable as follow : -.. code-block:: console +.. code-block:: sh PERFETTO_TRACE=1 my_vulkan_app @@ -188,7 +188,7 @@ To run the producer, follow these two simple steps: 1. Enable Panfrost unstable ioctls via kernel parameter: - .. code-block:: console + .. code-block:: sh modprobe panfrost unstable_ioctls=1 @@ -196,7 +196,7 @@ To run the producer, follow these two simple steps: 2. Run the producer: - .. code-block:: console + .. code-block:: sh ./build/pps-producer @@ -210,7 +210,7 @@ If the convenience script ``tools/tmux`` keeps copying artifacts to your ``SSH_TARGET`` without starting the tmux session, make sure you have ``tmux`` installed in your system. -.. code-block:: console +.. code-block:: sh apt install tmux diff --git a/docs/releasing.rst b/docs/releasing.rst index e5843fd3ad8..e5c845d1abf 100644 --- a/docs/releasing.rst +++ b/docs/releasing.rst @@ -177,7 +177,7 @@ to stabilization and bugfixing. Setup the branchpoint: -.. code-block:: console +.. code-block:: sh # Make sure main can carry on at the new version $EDITOR VERSION # bump the version number, keeping in mind the wrap around at the end of the year @@ -194,7 +194,7 @@ Once it has been merged, note the last commit *before* your "VERSION: bump to X.Y" as this is the branchpoint. This is ``$LAST_COMMIT`` in the command below: -.. code-block:: console +.. code-block:: sh VERSION=X.Y @@ -206,7 +206,7 @@ command below: Now that we have an official branchpoint, let's push the tag and create the branches: -.. code-block:: console +.. code-block:: sh git push origin $VERSION-branchpoint git checkout $VERSION-branchpoint @@ -220,7 +220,7 @@ and altered in way necessary, with the caveat that anything pushed to the ``X.Y`` branch must not be altered anymore. A convenient command to perform an interactive rebase over everything since the last release is: -.. code-block:: console +.. code-block:: sh git rebase -i mesa-$(cat VERSION) @@ -255,7 +255,7 @@ Most of the testing should already be done during the Here is one solution: -.. code-block:: console +.. code-block:: sh __glxgears_cmd='glxgears 2>&1 | grep -v "configuration file"' __es2info_cmd='es2_info 2>&1 | egrep "GL_VERSION|GL_RENDERER|.*dri\.so"' @@ -307,7 +307,7 @@ Use the release.sh script from X.Org `util-modular <https://gitlab.freedesktop.o Start the release process. -.. code-block:: console +.. code-block:: sh ../relative/path/to/release.sh . # append --dist if you've already done distcheck above @@ -329,7 +329,7 @@ in the ``mesa-X.Y.Z.announce`` template. Commit this change. Don't forget to push the commits to both the ``staging/X.Y`` branch and the ``X.Y`` branch: -.. code-block:: console +.. code-block:: sh git push origin HEAD:staging/X.Y git push origin HEAD:X.Y @@ -340,14 +340,14 @@ Back on mesa main, add the new release notes into the tree Something like the following steps will do the trick: -.. code-block:: console +.. code-block:: sh git cherry-pick -x X.Y~1 git cherry-pick -x X.Y Then run the -.. code-block:: console +.. code-block:: sh ./bin/post_version.py X.Y.Z @@ -356,7 +356,7 @@ docs/relnotes.rst and docs/release-calendar.csv. It will then generate a Git commit automatically. Check that everything looks correct and push: -.. code-block:: console +.. code-block:: sh git push origin main X.Y diff --git a/docs/repository.rst b/docs/repository.rst index a3de1346ed6..93fc6d67cf5 100644 --- a/docs/repository.rst +++ b/docs/repository.rst @@ -26,19 +26,19 @@ To get the Mesa sources anonymously (read-only): #. Install the Git software on your computer if needed. #. Get an initial, local copy of the repository with: - .. code-block:: console + .. code-block:: sh git clone https://gitlab.freedesktop.org/mesa/mesa.git #. Later, you can update your tree from the upstream repository with: - .. code-block:: console + .. code-block:: sh git pull origin #. If you also want the Mesa demos/tests repository: - .. code-block:: console + .. code-block:: sh git clone https://gitlab.freedesktop.org/mesa/demos.git @@ -77,7 +77,7 @@ tokens <https://gitlab.freedesktop.org/profile/personal_access_tokens>`__ to push over HTTPS if ssh does not suit your needs. In this case, create a token, and put it in the URL as shown here: -.. code-block:: console +.. code-block:: sh git remote set-url --push origin https://USER:to...@gitlab.freedesktop.org/your~user~name/mesa.git @@ -89,7 +89,7 @@ Windows <https://git-scm.com/book/en/v2/Getting-Started-Installing-Git#_installi you'll want to enable automatic CR/LF conversion in your local copy of the repository: -.. code-block:: console +.. code-block:: sh git config --global core.autocrlf true @@ -118,7 +118,7 @@ Developer Git Tips If you try to do a pull by just saying\ ``git pull`` and Git complains that you have not specified a branch, try: - .. code-block:: console + .. code-block:: sh git config branch.main.remote origin git config branch.main.merge main @@ -137,7 +137,7 @@ Developer Git Tips If it has been awhile since you've done the initial clone, try - .. code-block:: console + .. code-block:: sh git pull @@ -145,7 +145,7 @@ Developer Git Tips Make your changes and use - .. code-block:: console + .. code-block:: sh git add <files to commit> git commit @@ -161,7 +161,7 @@ Developer Git Tips To avoid this, - .. code-block:: console + .. code-block:: sh git pull --rebase git push @@ -181,7 +181,7 @@ Developer Git Tips If you want the rebase action to be the default action, then - .. code-block:: console + .. code-block:: sh git config branch.main.rebase true git config --global branch.autosetuprebase=always diff --git a/docs/shading.rst b/docs/shading.rst index bc3616819fc..96ce5ee85c0 100644 --- a/docs/shading.rst +++ b/docs/shading.rst @@ -144,7 +144,7 @@ installed as the binary ``glsl_compiler``. Here's an example of using the compiler to compile a vertex shader and emit :ext:`GL_ARB_vertex_program`-style instructions: -.. code-block:: console +.. code-block:: sh src/compiler/glsl/glsl_compiler --version XXX --dump-ast myshader.vert diff --git a/docs/submittingpatches.rst b/docs/submittingpatches.rst index 8c1c88e3ff0..3e227270c6f 100644 --- a/docs/submittingpatches.rst +++ b/docs/submittingpatches.rst @@ -174,7 +174,7 @@ to test this is to make use of the \`git rebase\` command, to run your tests on each commit. Assuming your branch is based off ``origin/main``, you can run: -.. code-block:: console +.. code-block:: sh $ git rebase --interactive --exec "meson test -C build/" origin/main @@ -433,7 +433,7 @@ Git tips - ``git rebase -i ...`` is your friend. Don't be afraid to use it. - Apply a fixup to commit FOO. - .. code-block:: console + .. code-block:: sh git add ... git commit --fixup=FOO @@ -441,6 +441,6 @@ Git tips - Test for build breakage between patches e.g last 8 commits. - .. code-block:: console + .. code-block:: sh git rebase -i --exec="ninja -C build/" HEAD~8 diff --git a/docs/xlibdriver.rst b/docs/xlibdriver.rst index 82493fcc368..000bfe36607 100644 --- a/docs/xlibdriver.rst +++ b/docs/xlibdriver.rst @@ -85,7 +85,7 @@ Hardware overlay planes are supported by the Xlib driver. To determine if your X server has overlay support you can test for the SERVER_OVERLAY_VISUALS property: -.. code-block:: console +.. code-block:: sh xprop -root | grep SERVER_OVERLAY_VISUALS
