The upload/download/decompression functions aren't all that specific to GL; I imagine we'll eventually need them for Vulkan as well.
Good point.
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?
I don't care strongly about this, though, at least not for this patch which touches only a couple lines (not counting the incidental change to stdint types.)
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.
Of course, it's tradeoffs, and if we want format_texture_info[] to be maximally tight and readable at the cost of not putting everything in the same place, then I understand that. I don't particularly like it, though; I'd rather have the code make maximal *sense* to a new developer, and I feel like format_texture_info[] is readable enough regardless. But I won't argue about it either.
FWIW, I think color fixups are the only thing I ended up moving to format_texture_info[]. The others mentioned, i.e. format_srgb_info[], format_decompress_info[], format_block_info[], really are orthogonal, and moreover they're inherent properties of the d3d format, not tied to a backend at all.
(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.)