On Fri Jul 7 08:04:06 2023 +0000, Rémi Bernon wrote:
> Sorry, I should've checked that.
> Fwiw if the module doesn't export anything in particular it should not
> really matter how it's named, the classes are registered with whatever
> module implements them and the code reads the module name from the registry.
Do you want me to create a new MR where I rename it? I agree that it should be in the correct dll, sorry for messing that up.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38336
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3238