ZDoom

What it does right now is generate the mipmap always. The sampler then controls if it is used or not. The consequence of that is of course wasted memory for any texture only used for 2D (approx 50% high memory usage for those textures). It isn't ideal, but I can personally live with it.

Only alternative is to default to not create mipmap, then create a new texture if anyone attempts to bind a mipmapping sampler. That will fragment allocations and due to that probably only save maybe half of the memory. All in all we're just lucky Doom is so old that texture memory usage is pretty low by today's standard anyway.

The thing is, it doesn't know. Remember, this is Doom. And in Doom everything is possible. Joking aside, ZDoom does allow using any patch as a texture in the map, even TITLEPIC or the map names (WILV**) So the best that can be done is saying 'currently I do not need a mipmap, but that can change randomly and unexpectedly.'

Sorry.

Okay, I cherry-picked the commit. Maybe sometime in the future the general texture creation code could include a hint if mipmapping is really needed.

Vulkan is dpJudas's baby, let him decide.

Graf, are you OK with merging my PR?

In that case, I think _mental_'s PR 842 implementation is correct. It disables the mipmaps in the same way as the OpenGL backend does (in the OGL case it has to because otherwise the texture would be considered incomplete).

Let's not discuss the bad design decisions in OpenGL. The API had a bad way of making the least efficient way to do things seem like the optimal solution.

There's really no need to copy this quirk to the Vulkan renderer. 2D rendering should disable mipmaps. Otherwise it's necessary to disable the NPOT scaling factors.

In a time with even less memory the importance of knowing what a texture needs up front only becomes even more important. There is a reason OpenGL is the only API the last 25 years that doesn't require you to tell the system up front how many mipmap levels you need.

I can make the Vulkan backend support "late mipmap generation" too, but it means I need to allocate the memory up front or use extra memory during the generation now because the original memory allocation turned out to be too small.

Nice for not allocating memory that's not needed.
Remember: This code comes from times when graphics cards had a lot less RAM than today and had to run on even older ones.

Nice for hacks you mean.

That's nice about OpenGL: You can create the mipmaps on demand. Vulkan can't.

Looking at the GL code for this stuff it has a nice little gem:
Seems the hwrenderer layer has no clue up front whether anything needs mipmapping or not. Looking at that, what _mental_ did with the sampler may actually be the best way of dealing with it unless someone wants to volunteer for a hwrenderer layer refactor of this thing.

_mental_ wrote: In fact, this topic should be moved to Vulkan render bugs with its title changed accordingly.

Done.

Mipmaps are not created for font textures because of their clamping mode. This works correctly in OpenGL backend but not in Vulkan one.
In fact, this topic should be moved to Vulkan render bugs with its title changed accordingly.
No need to remove any scaling factors. Let’s fix ignored clamping mode in Vulkan backend.
I think my PR is wrong. We need to pass clamp value to VkHardwareTexture like in OpenGL backend.

I'll never understand what the obsession with those scaling modes is. 5x and 6x barely give an advantage, for any normal use 4x with texture filtering is enough. The same is true for 3x, it barely makes a difference to 2x or 4x. Fact is that those odd factors have a degrading effect on the mipmaps which isn't present in 2x and 4x which makes these look better in most cases than the supposedly higher ones - except for extreme closeups.