Are there any penalties when always using target textures instead of static ones?

(I originally posted this to Stack Overflow, but haven’t received any reply, so I’m trying here.)

I know the difference between SDL_TEXTUREACCESS_STATIC and SDL_TEXTUREACCESS_TARGET. I’m writing an SDL backend for a game whose platform-independent core doesn’t tell the platform-dependent texture allocator whether or not the texture will just be blitted to the screen or whether the texture is also used as a target itself.

Thus, my SDL backend’s texture allocator has to use SDL_TEXTUREACCESS_TARGET instead of SDL_TEXTUREACCESS_STATIC for every texture it allocates because it doesn’t know at allocation time whether the texture will only be blitted or if it is also used as a target.

In practice then, however, there will be many textures which are allocated as SDL_TEXTUREACCESS_TARGET although they are never actually used as targets but they are just blitted to the screen without ever having their contents modified.

Is there any penalty in doing this? Suppose a texture is never used as a target itself but is still allocated using SDL_TEXTUREACCESS_TARGET. Does this come with major penalties? If it does, I could of course rewrite the platform-independent core to tell the platform-dependent part whether or not a texture will actually be used as a target but since this is a major endeavour I’d first like to ask whether or not there are actual penalties when simply using SDL_TEXTUREACCESS_TARGET for every texture, no matter if it is used as a target or not.

With the opengl, opengles and opengles2 renderers it’s a texture like all the others. The only overhead you pay is some time on creation and some memory for the framebuffer object it is attached to.

I don’t know much about Direct3D, but I think it’s similar there. Just be aware that Direct3D has this weird reset behavior on certain events like window resize which clears the render targets. SDL sends the SDL_RENDER_TARGETS_RESET and SDL_RENDER_DEVICE_RESET events if textures need to be updated.

Thanks, I didn’t know that on Direct3D target textures are reset on window resize or display mode change. That’s quite an important detail and a good reason to use static textures whenever possible.

In Direct3D (9, at least), if you don’t create a texture as “for use as a render target” it won’t work as such later, which is why SDL makes a distinction between STATIC and TARGET.

(This is the D3DUSAGE_RENDERTARGET flag in IDirect3DDevice9::CreateTexture’s “usage” parameter.)

In OpenGL, we need to create/reuse and assign a Framebuffer Object to the texture if it’s marked as TARGET, and would not be able to work if we didn’t do this.

Most importantly: SDL_SetRenderTarget() will return an error if you give it a texture that wasn’t created with SDL_TEXTUREACCESS_TARGET, for the reasons I list above, so it just won’t work regardless of the lower level rendering API it uses.