I don't care much for "wined3d_format_conversion_func", but *shrug*.
Any specific reason? I know that typedefs in general are unnecessary and reduce clarity, but function pointers are usually harder to read when embedded places. Or is it the name you dislike?
Essentially what you said: it doesn't seem terribly necessary here, and it makes it slightly harder to find e.g. the required prototype for these functions.
I don't care much for the reformatting of format_texture_info[] either. It's true that the table is perhaps a bit unwieldy in its current form, but I don't think this MR makes it better. The direction we had been moving in was to simply store optional information in separate tables, e.g. format_srgb_info[], format_decompress_info[], format_block_info[], and so on. The upload/download callbacks are in that category, as are "gl_srgb_internal" and "gl_rt_internal".
What bothers me about this is that the information in format_texture_info[], and the information I was going to move there over the course of this series, doesn't seem orthogonal to me. The table fundamentally decides what GL internal format to use for a given D3D format. gl_format and gl_type are (IIUC) derived directly from the internal format. upload, download, decompress, conv_byte_count, and fixups relate both conceptually and practically to the choice of a given internal format (or none) for a given d3d format. I guess gl_rt_internal / gl_srgb_internal *could* be orthogonal, but I don't see the others as being orthogonal.
I think that's a bit of a misunderstanding. gl_format and gl_type describe the "external" format. I.e., the format of the data that we pass to e.g. glTexSubImage2D(). Ideally that matches both the D3D format and the GL internal format because in that case we (as well as GL) can simply copy the data without any format conversion, but it doesn't have to. In particular, if gl_format and gl_type match the D3D format but not the GL internal format, OpenGL will do the conversion for us.
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: ```c {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.
(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.
In any case, just my two cents; Jan is the person you'll need to convince, not me. :D