This is really a continuation of the thread from the OpenGL coding: Advanced forum -
Aliasing one texture with another
Since it’s been answered, saying that it isn’t supported in the current core API or extensions, it’s probably now better to continue further discussions here on whether this is a worthwhile new change.
So, does anyone else have any views on whether this would be a useful addition, whether it would potentially simplify user-code, whether there will be performance issues, or whether it’s technically possible to achieve this with some/all current hardware, through the existing sampler addressing mode mechanisms, without any performance overhead?
(forgot to check ‘email notifications’… unfortunately have to reply to get topic notifications)
whether it would potentially simplify user-code
It might simplify user code, but it would almost certainly never be directly supported by the hardware. Which would mean more glslang compiler complexity, which is something glslang compilers absolutely do not need.
without any performance overhead?
Well, there’s going to be some performance overhead, since hardware can’t actually handle it. It will require that texture wrap modes (clamp, clamp-to-border, etc) will have to be emulated. And since a shader can’t control what the texture filter unit will access, the system will basically going to have to force the hardware to do NEAREST and then do filtering in the shader.
So no, it would never be equal to a regular texture access in performance.
Also, there’s always Texture arrays , which gives you a portion of what you want.