-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Description
Yesterday I experienced several crashes from within SDL3 while learning to use multiple Uniform blocks with a Fragment Shader in 3.4's SDL_Renderer.
While many crashes no doubt occur from inexperienced users passing incompatible combinations of array pointers and indices into them that may only manifest as issues once submitted to the GPU, I believe SDL3 would be better for verifying a supplied parameter in this instance, rather than trusting the user and attempting to index off an array.
Specifically by changing num_uniform_buffers from 2 to 1 in a SDL_GPUShaderCreateInfo, I experience a crash in SDL_CreateGPUGraphicsPipeline() as the lowest internal call from SDL_RenderPresent(), after earlier specifying a contradictory SDL_SetGPURenderStateFragmentUniforms() slot_index of 1 (i.e. the 2nd slot) in the same AppIterate cycle.
In SDL3.4, to create a RenderState, SDL_GPURenderStateCreateInfo has SDL_GPUShader *fragment_shader, which in turn is created via a SDL_GPUShaderCreateInfo having Uint32 num_uniform_buffers. It is my understanding that each Uniform buffer corresponds with the slot_index parameter of SDL_SetGPURenderStateFragmentUniforms(), and so when this function is called, it could simply check that the index isn't beyond the unchanging num_uniform_buffers value supplied when the shader was created, and if it is, this function can return false (being already defined with a bool return type) to avoid a crash later.
It seems the underlying SDL_PushGPUFragmentUniformData() can trust slot_index indexes to a valid reference via the backend-specific command_buffer, I've little doubt other SDL_GPU code paths depend upon this behaviour, thus suggest targetting a change to SDL_SetGPURenderStateFragmentUniforms(), but I could very well be mistaken as to the root cause of the crashes that VS2022 indicates originate from SDL_CreateGPUGraphicsPipeline() & the Vulkan AMD driver beyond that in my case.