Hi,
Il 12/12/22 22:42, Fabian Maurer ha scritto:
For a while now I'm curious, so I have to ask: Why is vkd3d an extra project?
Is that because it is reusable as standalone library? Just curious, because it's the only library in Wine that is a separate project.
Yeah, that's the main idea, as far as I know. Any Linux or macOS application that wishes to use D3D12 or any compiler in the vkd3d-shader library can do so without having to depend on the whole of Wine.
Wouldn't it have made sense to develop it as part of Wine to reuse the wine infrastructure and always have the most recent code for dx12/shaders?
While Wine ships with a convenience copy of vkd3d that is regularly (though not at every commit) updated, you are not bound to use that one. You can either copy a more recent version of vkd3d in Wine just before building it, or building vkd3d independently as a PE module and then using it within Wine (that's not really trivial, but see docs at https://wiki.winehq.org/Building_a_MinGW_WoW64_Wine_with_a_custom_vkd3d_buil...).
Also, many prominent downstreams of Wine, like Proton, automatically keep vkd3d more up-to-date, or even include patches that are not yet accepted in the official vkd3d repository.
My personal point of view is that "regular" versions of Wine (i.e., those that are not x.0) are not necessarily meant for an end-user. They are rather development snapshots taken every two weeks of whatever happened to be in the Wine repository at that time. Stable yearly x.0 releases are better tested and regressions are fixed, so it's what end users should use. For that case, vkd3d is released just before the code freeze, so that it is as up-to-date as possible in the stable release.
My two cents, Giovanni.