Hi there.
As long as you follow the rules of the dxvk license, which is very permissive, you can basically do what ever you want with your fork. Calling the version 1.10.4 imo makes sense since it follows in the footsteps of 1.10.3.

I'd suggest adding "-Sarek" to the dxvk version name so it properly shows that it is a fork and not the original project in both the hud and logs. Similar to what the async and gplasync forks did.

Thanks!!

i guess that are these lines in the meson.build file on the main folder (found these changes on the async.patch):

dxvk_version = vcs_tag(
  command: ['git', 'describe', '--dirty=-async'],
  input:  'version.h.in',
  output: 'version.h',
)

So i should change it from "-async" to "-sarek" or "-Sarek"
I also know that i should modify the release version under the meson.build, RELEASE file and on the src/dxvk/dxvk_instance.cpp files.

I am missing anything or with that it should be all good?

That could be one way at least yes. The output in the log would basically show as something like DXVK: v1.10.4-Sarek

Though thinking about it maybe it would make more sense to just make it write DXVK-Sarek: v1.10.4.
The async forks basically always follow the upstream versions (this repo) because they are always just that with a patch applied on top. So e.g. for gplasync you read DXVK: v2.5.1-2-gplasync as being dxvk version 2.5.1 with the second edition of the gplasync patch for that release applied on top.
Since you are going to release your own version numbers that doesn't follow this repos versions it might make it more clear that your fork is doing its own thing.

Off the top of my head you'd only need to change the string for what gets written in the log
https://github.com/doitsujin/dxvk/blob/218b67dd0c1eb3942668428a98f46a6fefefcf95/src/dxvk/dxvk_instance.cpp#L23
and for what gets written on the hud
https://github.com/doitsujin/dxvk/blob/218b67dd0c1eb3942668428a98f46a6fefefcf95/src/dxvk/hud/dxvk_hud_item.cpp#L107
So for the two above you'd change to

 Logger::info(str::format("DXVK-Sarek: ", DXVK_VERSION)); 

and

 renderer.drawText(16, position, 0xffffffffu, "DXVK-Sarek " DXVK_VERSION); 

respectively.

This is just a suggestion ofc.

I also realize now that going the --dirty= route would be a bit finicky in your case.

The async forks basically just apply a patch and then compile that and upload the binary without making the patched code a formal commit. So when they apply the patch the local git repo is dirty because it has file changes that haven't been staged and committed and they can then use that to make the build automatically add a -async when the patch is applied.
But since you are not working with just applying patches but instead cherry picking commits it wouldn't add a -Sarek at the end unless you had uncommitted changes.

Hope that makes sense

I follow your suggestion, compile and launch a game with the compiled version (it haves the async patch), using the DXVK_HUD=fps,version parameter:

And then Launch the same game with mangohud:

Its kinda odd to me the differences between one and the other. Is that normal?

I also realize now that going the --dirty= route would be a bit finicky in your case.

The async forks basically just apply a patch and then compile that and upload the binary without making the patched code a formal commit. So when they apply the patch the local git repo is dirty because it has file changes that haven't been staged and committed and they can then use that to make the build automatically add a -async when the patch is applied. But since you are not working with just applying patches but instead cherry picking commits it wouldn't add a -Sarek at the end unless you had uncommitted changes.

Hope that makes sense

Yeah dont worry it does make sense, in fact i will do it like that on the normal release, as i want to ship both a normal release and an async patched one.

Its kinda odd to me the differences between one and another. Is that normal?

Ah yea. That is because the dxvk log and hud texts are basically just some strings inserted in to some internal functions. External software like mangohud doesn't have access to that and instead usually use standard Vulkan means to get information about the application.
Mangohud reads the engine name that dxvk sets as "DXVK" and then just writes DXVK in the hud.
https://github.com/doitsujin/dxvk/blob/218b67dd0c1eb3942668428a98f46a6fefefcf95/src/dxvk/dxvk_instance.cpp#L186

You'll likely have noticed that mangohud only writes vkd3d when it sees vkd3d-proton is being used. That is because vkd3d-proton still only uses vkd3d as its engine name from when it was forked from upstream vkd3d. It basically can't tell via the engine name whether it is vkd3d-proton or vkd3d upstream so always just writes the latter.

I'd advise against, or at least caution, that you change the engine name to something like DXVK-Sarek. Drivers often use the engine name of a application to alter or apply specific behavior and so if you changed the engine name you might end up with buggy driver behavior since they don't see it as dxvk.
Here is an example of radv having specific behavior when it sees dxvk https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_device.c#L1235
Besides drivers it would also break mangohud being able to see dxvk when it sees your fork.

Edit:
The version number mangohud uses is also just the engine version that dxvk sets in a standard Vulkan struct.
https://github.com/doitsujin/dxvk/blob/218b67dd0c1eb3942668428a98f46a6fefefcf95/src/dxvk/dxvk_instance.cpp#L187

Its kinda odd to me the differences between one and the other. Is that normal?

The version string you are seeing on the HUD is calculated as a delta from the most recent git tag. So, assuming you tag something in your local branch (or on GitHub, if you want the CI flows to be affected) with v1.10.4, it should reflect properly. I think the tags need to be commented as well in order to be picked up, but with some trial and error you should be able to figure it out.

Its kinda odd to me the differences between one and the other. Is that normal?

The version string you are seeing on the HUD is calculated as a delta from the most recent git tag. So, assuming you tag something in your local branch (or on GitHub, if you want the CI flows to be affected) with v1.10.4, it should reflect properly. I think the tags need to be commented as well in order to be picked up, but with some trial and error you should be able to figure it out.

Now its working :)
On the version.h.in file i changed this line from:

#define DXVK_VERSION "@VCS_TAG@"

to

#define DXVK_VERSION "v1.10.4-async"

I know that this its a way lazier approach, but at least it works, thanks for the info.

Its kinda odd to me the differences between one and another. Is that normal?

Ah yea. That is because the dxvk log and hud texts are basically just some strings inserted in to some internal functions. External software like mangohud doesn't have access to that and instead usually use standard Vulkan means to get information about the application. Mangohud reads the engine name that dxvk sets as "DXVK" and then just writes DXVK in the hud.

https://github.com/doitsujin/dxvk/blob/218b67dd0c1eb3942668428a98f46a6fefefcf95/src/dxvk/dxvk_instance.cpp#L186

You'll likely have noticed that mangohud only writes vkd3d when it sees vkd3d-proton is being used. That is because vkd3d-proton still only uses vkd3d as its engine name from when it was forked from upstream vkd3d. It basically can't tell via the engine name whether it is vkd3d-proton or vkd3d upstream so always just writes the latter.

I'd advise against, or at least caution, that you change the engine name to something like DXVK-Sarek. Drivers often use the engine name of a application to alter or apply specific behavior and so if you changed the engine name you might end up with buggy driver behavior since they don't see it as dxvk. Here is an example of radv having specific behavior when it sees dxvk https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/radv_device.c#L1235 Besides drivers it would also break mangohud being able to see dxvk when it sees your fork.

Edit: The version number mangohud uses is also just the engine version that dxvk sets in a standard Vulkan struct.

https://github.com/doitsujin/dxvk/blob/218b67dd0c1eb3942668428a98f46a6fefefcf95/src/dxvk/dxvk_instance.cpp#L187

Okey, i am not touching anything related to the engine name then. Thanks for the help, i think that i can just work it from here, i will probably need to make a list of all the things to do to change the version lol.

dxvk-sarek-v1.10.4:

dxvk-sarek-async-v1.10.4:

Looks like everything its working as it should, thanks :)