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.
I asked on the SDL mailing list and was told that on OpenGL there aren't any major penalties but on Direct3D (which is the default driver on Windows), there's the problem that Direct3D resets target textures when the window size changes or when switching window display modes (fullscreen, windowed, etc.) So apps need to be prepared to handle the SDL_RENDER_TARGETS_RESET and update the content of target textures if the content needs to be preserved across window size changes, etc. So at least on Direct3D there is a major penalty when using target instead of static textures.