shadps4-emu/ext-SDL
1
0
Fork 0
mirror of https://github.com/shadps4-emu/ext-SDL.git synced 2024-11-23 10:09:48 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Sync SDL3 wiki -> header

Browse Source
This commit is contained in:
SDL Wiki Bot 2024-10-04 18:30:06 +00:00
parent f3285b01c8
commit f275731e18
1 changed files with 17 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
include/SDL3/SDL_gpu.h
View File

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