There are a few functions
which allow to use sdl for metal initialization, and access to metal device, MTLRenderCommandEncoder etc. So we are free to call
native metal function. But there is no any function to access a native metal texture from the SDL_Texture. It would be great to add something like
Honestly, it isn’t that big of a deal to create your own Metal textures, and you’ll have way more control over exactly what type of texture you’re creating. Including access to pixel formats that SDL_Renderer doesn’t support, mipmaps, etc.
Besides, most/all the stuff that lets you access the underlying Metal objects is probably going to go away in SDL3. Apparently the plan for SDL_Renderer in SDL3 is to replace the existing Metal and DX12 backends* with a unified one that uses the new GPU API that @icculus has been working on. And since the new GPU API intentionally doesn’t grant access to the underlying “real” API objects, there won’t be a way for SDL_Renderer to hand you a Metal command encoder, etc.
Doesn’t mean the new SDL_Renderer won’t let you access the new GPU API objects it creates, but you won’t be able to access the Metal, Vulkan, or DX12 objects they encapsulate.
*my understanding is that the DX11 and various OpenGL backends for SDL_Renderer will remain separate
Thank you for a reply.
It’s not too difficult to create a native metal texture. But I meant another scenario.
I can create a render target SDL_Texture, render to it by using some SDL functions, and then use native metal API (shaders) to implement some sort of postprocessing (blur, grayscale etc), and then use it again in SDL_Render* functions. Right now I can do such a trick if I use (opengl or opengles) as a render backend, and can’t do when I use the metal.
While I have an access to metal device and metal encoder, I don’t have an access to the metal texture.