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