docs: fix syntax highlighting on shell commands

Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27010>
2024-01-11 11:16:00 +00:00
parent eb505979ba
commit eb96a4bffe
24 changed files with 123 additions and 123 deletions
@@ -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

@@ -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 \
@@ -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
@@ -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/ \
@@ -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