From f275731e1891871da1e198f45f4deb3681be51a0 Mon Sep 17 00:00:00 2001 From: SDL Wiki Bot Date: Fri, 4 Oct 2024 18:30:06 +0000 Subject: [PATCH] Sync SDL3 wiki -> header --- include/SDL3/SDL_gpu.h | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/include/SDL3/SDL_gpu.h b/include/SDL3/SDL_gpu.h index 39770c702..fb19c3b06 100644 --- a/include/SDL3/SDL_gpu.h +++ b/include/SDL3/SDL_gpu.h @@ -30,9 +30,9 @@ * * A basic workflow might be something like this: * - * The app creates a GPU device with SDL_GPUCreateDevice, and assigns it to - * a window with SDL_ClaimWindowForGPUDevice--although strictly speaking you - * can render offscreen entirely, perhaps for image processing, and not use a + * The app creates a GPU device with SDL_GPUCreateDevice, and assigns it to a + * window with SDL_ClaimWindowForGPUDevice--although strictly speaking you can + * render offscreen entirely, perhaps for image processing, and not use a * window at all. * * Next the app prepares static data (things that are created once and used @@ -47,11 +47,11 @@ * SDL_CreateGPUGraphicsPipeline * * To render, the app creates one or more command buffers, with - * SDL_AcquireGPUCommandBuffer. Command buffers collect rendering - * instructions that will be submitted to the GPU in batch. Complex scenes can - * use multiple command buffers, maybe configured across multiple threads in - * parallel, as long as they are submitted in the correct order, but many apps - * will just need one command buffer per frame. + * SDL_AcquireGPUCommandBuffer. Command buffers collect rendering instructions + * that will be submitted to the GPU in batch. Complex scenes can use multiple + * command buffers, maybe configured across multiple threads in parallel, as + * long as they are submitted in the correct order, but many apps will just + * need one command buffer per frame. * * Rendering can happen to a texture (what other APIs call a "render target") * or it can happen to the swapchain texture (which is just a special texture @@ -66,8 +66,8 @@ * simultaneously. If the set of textures being rendered to needs to change, * the Render Pass must be ended and a new one must be begun. * - * The app calls SDL_BeginGPURenderPass. Then it sets states it needs for - * each draw: + * The app calls SDL_BeginGPURenderPass. Then it sets states it needs for each + * draw: * * - SDL_BindGPUGraphicsPipeline * - SDL_SetGPUViewport @@ -121,15 +121,17 @@ * creates the GPU device, the app lets the device know which shader formats * the app can provide. It will then select the appropriate backend depending * on the available shader formats and the backends available on the platform. - * When creating shaders, the app must provide the correct shader format for the - * selected backend. If you would like to learn more about why the API works - * this way, there is a detailed + * When creating shaders, the app must provide the correct shader format for + * the selected backend. If you would like to learn more about why the API + * works this way, there is a detailed * [blog post](https://moonside.games/posts/layers-all-the-way-down/) * explaining this situation. * * It is optimal for apps to pre-compile the shader formats they might use, - * but for ease of use SDL provides a [satellite single-header library](https://github.com/libsdl-org/SDL_gpu_shadercross) for - * performing runtime shader cross-compilation. + * but for ease of use SDL provides a + * [satellite single-header library](https://github.com/libsdl-org/SDL_gpu_shadercross + * ) + * for performing runtime shader cross-compilation. * * This is an extremely quick overview that leaves out several important * details. Already, though, one can see that GPU programming can be quite