docs: consistently upper-case VC4, V3D etc

This is how we're doing this elsewhere in the docs, and upper-casing is
a clear indication that this is a name.

Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19191>

docs/drivers/v3d.rst

@@ -1,25 +1,25 @@
 V3D
 ===
 
-Mesa's ``v3d`` graphics driver stack includes a `conformant GLES3.1
+Mesa's V3D graphics driver stack includes a `conformant GLES3.1
 driver
 <https://www.khronos.org/conformance/adopters/conformant-products/opengles#submission_882>`__
-called ``v3d`` and a Vulkan graphics driver called ``v3dv``, notably
+called V3D and a Vulkan graphics driver called V3DV, notably
 used on the Raspberry Pi 4.
 
-The v3d Mesa drivers communicate directly with the `v3d
+The V3D Mesa drivers communicate directly with the `V3D
 <https://www.kernel.org/doc/html/latest/gpu/v3d.html>`__ kernel DRM
 driver for scheduling GPU commands.  Additionally, on the Raspberry Pi
-4, the kernel uses the vc4 DRM driver for display support, so Mesa
+4, the kernel uses the VC4 DRM driver for display support, so Mesa
 exposes a ``vc4_dri.so`` using the kmsro helpers to do
 behind-the-scenes buffer management between the two kernel drivers,
-while executing rendering on the v3d kernel module.
+while executing rendering on the V3D kernel module.
 
 Initial development work was done on the Broadcom 7268 (V3D 3.3) and
 7278 (V3D 4.1).  Development since then has been on V3D 4.2, and
 though the 3.3 and 4.1 support continues to remain in tree, it is not
 tested any more.  Broadcom's reference software platforms do not make
-use of the open source v3d stack, but porting a particular hardware
+use of the open source V3D stack, but porting a particular hardware
 implementation to use it would still be possible.
 
 Hardware Documentation
@@ -30,7 +30,7 @@ series.
 
 For driver developers, Broadcom publicly released a `specification
 <https://docs.broadcom.com/doc/12358545>`__ PDF for the 21553, which
-is closely related to the vc4 GPU present in the Raspberry Pi.  They
+is closely related to the VC4 GPU present in the Raspberry Pi.  They
 also released a `snapshot <https://docs.broadcom.com/docs/12358546>`__
 of a corresponding Android graphics driver.  That graphics driver was
 ported to Raspbian for a demo, but was not expected to have ongoing
@@ -41,7 +41,7 @@ access to the V3D architecture specification for documentation of the
 GPU's programming model.  There is also a C++ software simulator
 called simpenrose, and the Mesa driver includes a backend
 (``src/broadcom/drm-shim/``) to use simpenrose from an x86 system with
-the i915 graphics driver with all of the vc4 rendering commands
+the i915 graphics driver with all of the VC4 rendering commands
 emulated on simpenrose and memcpyed to the real GPU.  Note that
 simpenrose's API drifts over time, so you need to be synced up with
 whatever version Mesa was last being developed against.

docs/drivers/vc4.rst

@@ -1,14 +1,14 @@
 VC4
 ===
 
-Mesa's ``vc4`` graphics driver supports multiple implementations of
+Mesa's VC4 graphics driver supports multiple implementations of
 Broadcom's VideoCore IV GPU. It is notably used in the Raspberry Pi 0
 through Raspberry Pi 3 hardware, and the driver is included as an
 option as of the 2016-02-09 Raspbian release using ``raspi-config``.
 On most other distributions such as Debian or Fedora, you need no
 configuration to enable the driver.
 
-This Mesa driver talks directly to the `vc4
+This Mesa driver talks directly to the `VC4
 <https://www.kernel.org/doc/html/latest/gpu/vc4.html>`__ kernel DRM
 driver for scheduling graphics commands, and that module also provides
 KMS display support.  The driver makes no use of the closed source VPU
@@ -18,7 +18,7 @@ GPU block from Linux.
 GLES2 support
 -------------
 
-The vc4 driver is a nearly conformant GLES2 driver, and the hardware
+The VC4 driver is a nearly conformant GLES2 driver, and the hardware
 has achieved GLES2 conformance with other driver stacks.
 
 OpenGL support
@@ -29,8 +29,8 @@ mostly correct but with a few caveats.
 
 * 4-byte index buffers.
 
-GLES2.0, and vc4, don't have ``GL_UNSIGNED_INT`` index buffers. To support
-them in vc4, we create a shadow copy of your index buffer with the
+GLES2.0, and VC4, don't have ``GL_UNSIGNED_INT`` index buffers. To support
+them in VC4, we create a shadow copy of your index buffer with the
 indices truncated to 2 bytes. This is incorrect (and will assertion
 fail in debug builds of Mesa) if any of the indices were >65535. To
 fix that, we would need to detect this case and rewrite the index
@@ -271,7 +271,7 @@ shader-db
 ---------
 
 shader-db is often used as a proxy for real-world app performance when
-working on the compiler in Mesa.  On vc4, there is a lot of
+working on the compiler in Mesa.  On VC4, there is a lot of
 state-dependent code in the shaders (like blending or vertex attribute
 format handling), so the typical `shader-db
 <https://gitlab.freedesktop.org/mesa/shader-db>`__ will miss important
@@ -291,7 +291,7 @@ Hardware Documentation
 
 For driver developers, Broadcom publicly released a `specification
 <https://docs.broadcom.com/doc/12358545>`__ PDF for the 21553, which
-is closely related to the vc4 GPU present in the Raspberry Pi.  They
+is closely related to the VC4 GPU present in the Raspberry Pi.  They
 also released a `snapshot <https://docs.broadcom.com/docs/12358546>`__
 of a corresponding Android graphics driver.  That graphics driver was
 ported to Raspbian for a demo, but was not expected to have ongoing
@@ -301,5 +301,5 @@ Developers with NDA access with Broadcom or Raspberry Pi can
 potentially get access to "simpenrose", the C software simulator of
 the GPU.  The Mesa driver includes a backend (`vc4_simulator.c`) to
 use simpenrose from an x86 system with the i915 graphics driver with
-all of the vc4 rendering commands emulated on simpenrose and memcpyed
+all of the VC4 rendering commands emulated on simpenrose and memcpyed
 to the real GPU.