HansKristian-Work / vkd3d-proton

Fork of VKD3D. Development branches for Proton's Direct3D 12 implementation.
GNU Lesser General Public License v2.1
1.75k stars 183 forks source link

Add VKD3D_FRAME_RATE environment variable #1998

Closed Tiagoquix closed 1 week ago

Tiagoquix commented 1 month ago

Basically the same as DXVK.

https://github.com/doitsujin/dxvk?tab=readme-ov-file#frame-rate-limit

https://github.com/doitsujin/dxvk/blob/master/src/util/util_fps_limiter.cpp

What would also be interesting would be to make this DXVK frame rate environment variable also work in VKD3D without having to create a new separate one just for VKD3D, but I don't know if it's possible because I imagine that the projects (DXVK and VKD3D) can be used independently one from the other.

One possible approach would be to create a variable with a "global" name (that is compatible with both projects) and recommend it as the new one, at the same time that DXVK_FRAME_RATE and VKD3D_FRAME_RATE would work with this new "global" variable (basically creating aliases).

HansKristian-Work commented 1 month ago

DXVK owns the outer DXGI layer for vkd3d-proton. Wouldn't DXVK's frame limiter apply to vkd3d-proton as well?

doitsujin commented 1 month ago

DXVK's frame rate limiter actually runs on the same thread that handles present waits and feeds back into app logic that way, rather than blocking DXGI present directly. We tried doing that in the initial implementation, but for some reason that caused some catastrophic frame pacing issues.

If we want this to work we'd probably want to bring our own logic and extend the swap chain interface further, so that DXVK config options also get applied properly. An argument for doing that would be something like supporting 60 Hz display modes in an environment that does not support mode switches (i.e. Proton), which is something I've been wanting to do in DXVK anyway.

shelterx commented 1 month ago

https://github.com/HansKristian-Work/vkd3d-proton/issues/1553

doitsujin commented 2 weeks ago

https://github.com/HansKristian-Work/vkd3d-proton/pull/2014 tentatively implements this.

Tiagoquix commented 2 weeks ago

If the frame rate limiter gets implemented, do you guys have any idea for a "global" variable name that works both for DXVK and VKD3D without the user needing to change between them?

I think something like DXVKD3D_FRAME_RATE (I agree, horrible name) may work. Another possible approach is to make DXVK_FRAME_RATE and VKD3D_FRAME_RATE work exactly the same (for all DX levels), but I think a single "global" variable is more desirable.

(Another possible names: VULKAN_FRAME_RATE, VK_FRAME_RATE, LINUX_VK_FRAME_RATE.)

doitsujin commented 2 weeks ago

The current implementation supports DXVK_FRAME_RATE, using any names that imply it applies to anything outside of dxvk/vkd3d-proton is not desireable since native Vulkan games exist.

Tiagoquix commented 2 weeks ago

Good observation. I think "DXVKD3D" or "VKD3DXVK" (I prefer the former) would not cause any confusion and could be used.

I dislike the idea of having two different variables for the same thing; even if it's DX 9/10/11 vs. 12, it's still DX in essence. As I see it, having two different variables would somewhat cause confusion for newcomers. An unified variable for both projects is the best approach, in my opinion.

shelterx commented 2 weeks ago

I get what you mean but honestly, DXVK/VKD3D do not share the same variables. I think a shared variable will add confusion and will break the approach the project uses.

Tiagoquix commented 2 weeks ago

I think there should be an exception only for this variable, since I think that many users only see the thing in its complete form (in this case, Proton), without really knowing what's under the hood. I don't think a shared variable in this case will add confusion considering that both projects share the same developers.

Edit: to clarify, I have all respect for the developers of both projects and greatly appreciate their work. I'm just trying to think from the perspective of a new user to the Linux gaming scene and trying to make life easier for the newcomers.

doitsujin commented 2 weeks ago

I still don't understand what the problem is, DXVK_FRAME_RATE applies to both DXVK and the PR as an alias, why do we need to give it some turbocursed name that nobody is going to be able to remember?

Tiagoquix commented 2 weeks ago

Edit: TL;DR: Do not create VKD3D_FRAME_RATE; instead, share DXVK_FRAME_RATE between DXVK and VKD3D to avoid confusion about 2 variables doing the same thing for what is, in essence, DirectX. Basically the same thing as it is now, but without the part that creates VKD3D_FRAME_RATE.

My original idea is that both DXVK_FRAME_RATE and VKD3D_FRAME_RATE would work interchangeably with each other (that is, the VKD3D env. would also work in DXVK games).

I'm not sure, but I think the current form (which I believe is DXVK for everything and VKD3D only for DX12) is good enough. However, I think this would possibly cause confusion for newcomers as there would be two variables that do the same thing (DXVK acting on everything, and VKD3D acting only for DX12).

A possible idea then, following this new reasoning, would be to leave only the DXVK_FRAME_RATE variable and not create the VKD3D_FRAME_RATE variable. This way, only one "global" variable is used, and we already take advantage of the name of the existing one. With this, we could include the DXVK_FRAME_RATE variable in the VKD3D README and not have to create a new one.

My central idea here is to avoid having to have two separate ones that do the same thing (even though they are for different DX levels).

To clarify, my original idea was for VKD3D_FRAME_RATE to only apply for VKD3D (as it seems to be currently in the PR); however, since DXVK_FRAME_RATE will also work as an alias, then I now think that we should only have one instead of two. (It would be valid because, as far as I know, VKD3D seems to rely on some DXVK things to function, and cannot exist without it.)

shelterx commented 1 week ago

Well, I'm not a newcomer to gaming in Linux anymore but I was. And the whole VKD3D/DXVK/proton/heroic/bottles/lutris thing was very confusing at first. I don't think a single variables naming will matter much. It's not my thing to decide but my logic really says NO! when using a DXVK variable in vkd3d-proton.

Tiagoquix commented 1 week ago

Yeah, logically it doesn't make sense for a DXVK variable to apply on a VKD3D scenario. I think the current approach is the best: we will have the two variables, and DXVK_FRAME_RATE will also work - the logic will still be that of VKD3D; it'll just recognize if the DXVK variable is set and proceed accordingly.

Tiagoquix commented 1 week ago

@doitsujin Do you plan to add VKD3D_FRAME_RATE as an alias in the DXVK project as well?

doitsujin commented 1 week ago

No, and for the 10th time, I really don't see why this is such a huge problem when we have a) the DXVK alias that works for both and b) dxvk.conf overrides which also work for both.

Anyway, merged.