The point though, is that most of the formats in the table simply don't need those extra fields. Most of them don't have different gl_rt_internal or gl_srgb_internal formats, and most of them don't need upload/download conversion functions. I.e., most of the entries could look like this:
{WINED3DFMT_R32_FLOAT, GL_RGB32F_ARB, ARB_TEXTURE_FLOAT}, [...] {WINED3DFMT_R16G16B16A16_UINT, GL_RGBA16UI, EXT_TEXTURE_INTEGER}, [...]and then we'd need only a relatively modest number of entries for the more complicated formats.
Hmm, that's more workable. We could probably do a lot already by reordering the fields so all the optional ones are at the end.
I might try adjusting the table a bit. But I might also just drop this series and work on upstreaming more important things for now.
(I don't know what to do about the "caps" flags; they're kind of an awkward combination of backend-specific and non-backend-specific information.)
Well, there's format_base_flags[]. Note also that with modern OpenGL we can largely use the same strategy we use for Vulkan, and test format capabilities with ARB_internalformat_query2. For older GL, the format being supported at all generally implies it supports texturing, filtering, and so on. WINED3D_QUIRK_BROKEN_RGBA16 is a notable exception.
Yeah, but there's also a lot of hardcoded lists in extensions, which is irritating. And then there's cases where we intentionally omit flags because they confuse applications, which really shouldn't be in format_texture_info, but probably deserves its own table.
In any case, just my two cents; Jan is the person you'll need to convince, not me. :D
I'll take my cues as often as I can from someone who's maintained this area for a decade before I even started working on the project ;-)