diff --git a/include/SDL3/SDL_gpu.h b/include/SDL3/SDL_gpu.h
index 9b7149801a..914ce76562 100644
--- a/include/SDL3/SDL_gpu.h
+++ b/include/SDL3/SDL_gpu.h
@@ -464,10 +464,15 @@ typedef enum SDL_GPUTextureFormat
  * A texture must have at least one usage flag. Note that some usage flag
  * combinations are invalid.
  *
- * With regards to compute storage usage, READ | WRITE means that you can have shader A that only writes into the texture and shader B that only reads from the texture and bind the same texture to either shader respectively.
- * SIMULTANEOUS means that you can do reads and writes within the same shader or compute pass. It also implies that atomic ops can be used, since those are read-modify-write operations.
- * If you use SIMULTANEOUS, you are responsible for avoiding data races, as there is no data synchronization within a compute pass.
- * Note that SIMULTANEOUS usage is only supported by a limited number of texture formats.
+ * With regards to compute storage usage, READ | WRITE means that you can have
+ * shader A that only writes into the texture and shader B that only reads
+ * from the texture and bind the same texture to either shader respectively.
+ * SIMULTANEOUS means that you can do reads and writes within the same shader
+ * or compute pass. It also implies that atomic ops can be used, since those
+ * are read-modify-write operations. If you use SIMULTANEOUS, you are
+ * responsible for avoiding data races, as there is no data synchronization
+ * within a compute pass. Note that SIMULTANEOUS usage is only supported by a
+ * limited number of texture formats.
  *
  * \since This datatype is available since SDL 3.0.0
  *
@@ -542,8 +547,8 @@ typedef enum SDL_GPUCubeMapFace
  * A buffer must have at least one usage flag. Note that some usage flag
  * combinations are invalid.
  *
- * Unlike textures, READ | WRITE can be used for simultaneous read-write usage.
- * The same data synchronization concerns as textures apply.
+ * Unlike textures, READ | WRITE can be used for simultaneous read-write
+ * usage. The same data synchronization concerns as textures apply.
  *
  * \since This datatype is available since SDL 3.0.0
  *
@@ -2817,21 +2822,22 @@ extern SDL_DECLSPEC void SDLCALL SDL_EndGPURenderPass(
  *
  * A compute pass is defined by a set of texture subresources and buffers that
  * may be written to by compute pipelines. These textures and buffers must
- * have been created with the COMPUTE_STORAGE_WRITE bit or the COMPUTE_STORAGE_SIMULTANEOUS_READ_WRITE bit.
- * If you do not create a texture with COMPUTE_STORAGE_SIMULTANEOUS_READ_WRITE, you must not read from the texture in the compute pass.
- * All operations
- * related to compute pipelines must take place inside of a compute pass. You
- * must not begin another compute pass, or a render pass or copy pass before
- * ending the compute pass.
+ * have been created with the COMPUTE_STORAGE_WRITE bit or the
+ * COMPUTE_STORAGE_SIMULTANEOUS_READ_WRITE bit. If you do not create a texture
+ * with COMPUTE_STORAGE_SIMULTANEOUS_READ_WRITE, you must not read from the
+ * texture in the compute pass. All operations related to compute pipelines
+ * must take place inside of a compute pass. You must not begin another
+ * compute pass, or a render pass or copy pass before ending the compute pass.
  *
- * A VERY IMPORTANT NOTE - Reads and writes in compute passes are NOT implicitly synchronized.
- * This means you may cause data races by both reading and writing a resource region in a compute pass,
- * or by writing multiple times to a resource region.
- * If your compute work depends on reading the completed output from a previous
- * dispatch, you MUST end the current compute pass and begin a new one before
- * you can safely access the data. Otherwise you will receive unexpected results.
- * Reading and writing a texture in the same compute pass is only supported by specific texture formats.
- * Make sure you check the format support!
+ * A VERY IMPORTANT NOTE - Reads and writes in compute passes are NOT
+ * implicitly synchronized. This means you may cause data races by both
+ * reading and writing a resource region in a compute pass, or by writing
+ * multiple times to a resource region. If your compute work depends on
+ * reading the completed output from a previous dispatch, you MUST end the
+ * current compute pass and begin a new one before you can safely access the
+ * data. Otherwise you will receive unexpected results. Reading and writing a
+ * texture in the same compute pass is only supported by specific texture
+ * formats. Make sure you check the format support!
  *
  * \param command_buffer a command buffer.
  * \param storage_texture_bindings an array of writeable storage texture