OK, let’s say you have a 128x128 texture, which has a total of 7 mipmap levels. Now, you want to reallocate it to being a 128x128 with only 1 mipmap level. So you call glTexImage on the base level of 0. Then you call glTexImage on all of the others with… what?
If you think that passing NULL for the pixel data is “destroying” the mipmap in some way… no, that’s not how it works. If you think passing 0 for the sizes will “destroy” the mipmap, you’d be more likely to be correct. However, absolutely nothing in OpenGL guarantees that the driver will deallocate the old memory. It could simply keep that memory around, since it would be appropriately sized for that mipmap level. And you have to change the minimum mipmap level anyway, since the texture won’t be complete if you don’t. So the driver would be perfectly justified in just keeping the memory around.
… I fail to see how the IHV’s forbidding a practice that leads to poor performance behavior is considered “monopolism”. It’s not like the IHVs are competing with makers of software; how would they be advantaged in the marketplace by denying software makers an API? Unless that API is a bad idea, of course.
Also, there’s more than one IHV, so it would be oligopolism
It’s not a question of “could”. The fact that ARB_sparse_texture exists proves that drivers can make individual mipmap levels somewhat ephemeral. There’s every reason to believe that drivers could allow a function to explicitly deallocate a mipmap level.
The question is more of when, how, and whether it’s a good idea. Sparse Textures are a use case that IHVs want to support; yours is not. There’s probably a good reason for that.
Not necessarily. If every time you delete or allocate texture memory, you drop a frame, then it doesn’t really matter how often it happens. You lose smoothness whenever the user does whatever he does to cause it to happen.
Or you could just keep the mipmaps around and unused until you need them again.
Like mhagain said, let the driver do its job of paging things into and out of video memory as needed.