This is not an engine, my friend; the game has to implement it, not the driver. You should close this one.

@cloudishBenne Hi there.
As pointed out above Anti-Lag 2 needs integration in the game for it to work. You are probably thinking of Anti-Lag 1 which is a driver level thing.
Though dxvk and vkd3d-proton would probably have to implement support for using Anti-Lag 2 in games that support it same as with Reflex. The AMD driver in use would need to support it too ofc.

@Blisto91 Yes, that's what i meant, adding support for it equal to what happened to Reflex. R5Reloaded will have it implemented ingame with the next release.
Also thank you for mentioning the additional requirement of a driver side implementation. If someone of you has useful information, what i should mention in a mesa issue, i will open one there.

I am not a dev (tester) so I can't comment on any technical specifics or requirements. From the driver side I imagine it just have to support the VK_AMD_anti_lag extension.

I don't know if the amd ags vendor library in Proton Wine needs to be worked on for support too. Might be likely like with dxvk-nvapi needing to support Reflex.
But either way driver support would probably be a first step.

I am not a dev (tester) so I can't comment on any technical specifics or requirements. From the driver side I imagine it just have to support the VK_AMD_anti_lag extension.

I don't know if the amd ags vendor library in Proton Wine needs to be worked on for support too. Might be likely like with dxvk-nvapi needing to support Reflex. But either way driver support would probably be a first step.

The VK_AMD_anti_lag implementation is in the works, but there is focus on other priorities. It will be addressed eventually.

How do you know it is in the works

How do you know it is in the works

Samuel was discussing the implementation, but he found himself constrained by VK_KHR_shader_float_controls2. Nevertheless, he began drafting it prior to thinking about creating a merge request.

How do you know it is in the works

Samuel was discussing the implementation, but he found himself constrained by VK_KHR_shader_float_controls2. Nevertheless, he began drafting it prior to thinking about creating a merge request.

Thank you for this information!

So this means writing an issue would be redundant i guess?

Do you have a link to his work?

How do you know it is in the works

Samuel was discussing the implementation, but he found himself constrained by VK_KHR_shader_float_controls2. Nevertheless, he began drafting it prior to thinking about creating a merge request.

Thank you for this information!

So this means writing an issue would be redundant i guess?

Do you have a link to his work?

No, there's no merge request open yet. I'll post it when he opens it.

might be a stupid question but does mesa need to implement this extension before it can be used by dxvk? there is no open issue/MRs for implementing it unless I missed something

Afaik yes. But i am not aware of any current work in regards to supporting this at the moment.

FYI Mesa now has a MR for Anti Lag implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34242

It seems that on VKD3D side for DX12, AMD Anti-Lag is supported since version 3.0 (if you search the codebase for anti_lag and low_latency).

One practical challenge is that the way AMD initializes this is by calling GetModuleHandleA on one of their driver's DLLs and then GetProcAddress to get a function to create their extension. For DX12 that's amdxc64.dll and AmdExtD3DCreateInterface, while for DX11 it's amdxx64.dll and AmdDxExtCreate11

It seems that for DX12+VKD3D the downstream Wine Proton fork specifically has the DLL amdxc64.dll implemented with code for handling that: https://github.com/ValveSoftware/wine/blob/eb63de9c3c08bb222dd439e1cea3be4217d3d0f9/dlls/amdxc64/main.c#L224-L236

The equivalent for amdxx64.dll is missing, so that would need to be created first.

It doesn't seem like this should be impossible, in principle the DX12 and DX11 versions of the interfaces seem similar, there's just some differences in how they're created (DX11 one uses some weird request identifier magic number instead of GUID like with DX12? also seems not to depend on the DX device at all?). Other than that, they also use a single function call on the interface with the APIData_v1 struct (DX12 also has APIData_v2, but in VKD3D it's basically a stub; it seems to matter for working together with frame-gen, but it seems AMD never bothered to do the same thing for DX11 interface).

Given that DXVK already supports Reflex too, it should probably not be too hard to parrot over the implementation based on how VKD3D implemented it, maybe...

And just as I was searching for AmdDxExtCreate11, I found this: https://github.com/Etaash-mathamsetty/wine-valve/blob/e42060e76656d4cd547dce29f9140ad4805ad478/dlls/atidxx64/main.c#L637-L653 ...commits made 3 days ago.

So it seems @Etaash-mathamsetty is maybe working on this? :) Or just some preliminary unrelated ground work for future expansion?

For D3D11, we aren't given a d3d11 device to use the vulkan extension with unfortunately. So any anti lag implementation would have to be done within that DLL somehow. As for the rest of the code it was written mostly in 2023/2024 to get native amd ags working in proton (which turned out to be successful). Recently fixed up one last issue with it and it's pretty much done now