This is a part of a larger effort to reorganize wined3d a bit so that backend functions are fully quarantined into their own files. There are a few advantages to this:
* We avoid including (large) headers in files that don't need them.
* This has helped me find functions that are currently incorrectly tied to backends [e.g. wined3d_texture_update_desc(), wined3d_texture_set_lod()].
* This may also help find code (struct members, helpers, etc.) which should be made local to a backend.
* I find that this aids the reader in logically separating wined3d code. For some time the wined3d code base has resisted modularity of compilation units, simply on the grounds that this is not necessary. I find files comprising several thousand lines to be a bit unwieldy, however, and that comprehension and navigation are eased when drawing physical lines even when such separation was already obvious. It also can be nice for compilation speed.
There are a few steps to this:
- move GL and Vulkan declarations to wined3d_gl.h and wined3d_vk.h respectively
- introduce "resource_gl.c" and "resource_vk.c", and move most resource code to those functions. This collapses the separation between buffer, texture, sampler, and view code, though, and there may be some benefit in keeping those separate.
It's worth mentioning though that the bulk of those files ends up being the texture code. It's also worth mentioning that resources are generally interrelated—e.g. views delegate to buffers or textures—and we've talked about generalizing more of the buffer/texture code to share more code. Of course, *everything* is interrelated, so the lines that we're drawing now are kind of arbitrary. I at least find that GL/Vulkan are *useful* lines to draw.
- add format_gl.c, because there are about 3000 lines of code to deal with GL format detection.
- add ffp_gl.c, which contains the fixed-function vertex and fragment pipelines. This is about 3500 lines.
- move other functions to backend-specific adapter or context functions, where it makes sense. Swapchain code mostly gets moved to context_*.c, though I'm not sure whether that makes the most sense or not.