AMD literally made an "internal cheat" for cs2. This is a widely known guaranteed ban and likely among most people (if you modify the game engine then you get banned). Even with weak anticheat like VAC.
This means AMD didn't work with valve at all on this feature, a feature I assume both parties would be interested in. This would be one of the biggest esport games for the anti-lag feature that amd could advertise as supporting.
On top of not contacting valve, they had the expertise to do this, but somehow didn't realize they would get banned?
Somewhat hilariously there's no way they did this for valorant - that game wont even launch if you have debug tools open (unless amd is so dense they worked around that).
I still hope they unbanned players who were hit by this - my opinion is that players should be expected to know the internal workings of anti-lag or of VAC, and that AMD is a big enough player in the market for people to "just trust" with drivers. This isn't some random mouse or keyboard software from Alibaba.
They certainly will if they haven't already. Last I heard they were waiting for amd to fix their code before they unban people.
This is the third false-VAC since the cs2 beta. First was a unprotected yaw command (no commands should get you vacced unless they're protected by sv_cheats), windows 7 users, and now amd anti-lag+.
Although in the case of AMD, this is definitely not valve's fault. They detected exactly what they're supposed to.
drivers are a black box, yes, but in this case, the driver is trying to get the game to act in a certain specific way, and it needs to either have these calls added to the game engine, or it needs to inject itself and rewrite the game code (detouring) dynamically at runtime.
reflex and antilag basically work by flipping the vsync model around. instead of "render a frame -> wait for the monitor to be ready to draw", it's "wait -> render". And by dynamically adjusting the wait time, you can have the frame ready at the last possible moment before the monitor is ready. This means game state is $WAIT_TIME milliseconds fresher, and you've reduced latency by that amount.
well, that means you have to have some method to control when the game starts doing the game loop. So you have to be inside the engine somehow - either you have a WAIT_FOR_REFLEX() in the code, or you grab control of the frame queue and don't return control until you're ready, and you just block until the right moment.
They should already have enough control to implement what you describe without changing the game at all, unless the game is doing something to introduce latency outside the drivers control such as threaded rendering
I’m very interested to know what they did beyond standard low latency frame scheduling, and why it required hooking into games to the point of triggering anti cheat
> drivers are a black box, yes, but in this case, the driver is trying to get the game to act in a certain specific way, and it needs to either have these calls added to the game engine, or it needs to inject itself and rewrite the game code (detouring) dynamically at runtime.
isn't this pretty much exactly what graphics drivers have been for years now though? game-specific behavior, day-one driver updates, and all that. the only (unfortunately) novel thing here is doing this without the express consent and cooperation of the game's developer.
> the only (unfortunately) novel thing here is doing this without the express consent and cooperation of the game's developer.
Nvidia did it "properly" and worked with valve to develop it in-engine. I could definitely be wrong but I think many of the game-specific optimizations have to to with how they handle the draw-calls, not modifying the actual games themselves.
I'm not sure I understand - is AMD merely refreshing frames in a faster way than usual (something that players with better equipment already are doing), or are they also interfering with the game process in some way (ie actively adjusting your aim or performing other commands)?
Parts of the graphics driver is loaded into the application process (as a DLL), so it's not quite that suspicious. But once they start modifying the application code itself, that's when the problem happens.
Nit: AFAIU there is no literal modification of machine code going on—instead the import address table (IAT, the Windows counterpart of Linux’s GOT) is patched (the Windows tradition calls this “detoured”, from the quite popular Microsoft hack[1] that does it).
There are plenty of perfectly ordinary reasons to do this, e.g. you have an untrusted binary and you want to analyze it to determine if it's malicious, or hook its encryption function so you can decrypt the traffic and see what it's sending out of your machine. Program debuggers do this in general. Some enterprise BS does this so it can scan TLS traffic. It has long been common to do this sort of thing specifically to games and generally to precompiled binaries without published source code, to mod them in ways that aren't related to cheating. It can make sense for interpreted languages to sandbox the interpreted code into its own process, which the interpreter process might then be writing to.
> you have an untrusted binary and you want to analyze it to determine if it's malicious, or hook its encryption function so you can decrypt the traffic and see what it's sending out of your machine. Program debuggers do this in general.
You would have to be manually looking for it then? Also if you do this to the main engine.dll you WILL be banned.
Most of the things you're mentioning you wouldn't hook the main engine.dll, you'd be hooking the system api's, directx, etc.
I'm not sure many people commenting here play competitive games, it's a ruthless cat-mouse war with cheaters. Anticheat is NOT friendly to modding any of the game code. Yes some anti-cheats will ban you for use autohotkey.
Don't graphics pipelines compile shaders though? Are you going to ask me to run an optimizing compiler on your shader and then complain I altered it? Or do you want me to run the raw text on the hardware somehow?
Yes, but, the way their antilag works is identical to a cheat - it's actually hooking/detouring the game's own functions, which any anticheat will see as an obvious hack.
NVIDIA's Reflex actually requires that it be integrated into the game code by developers (which they then provide) rather than trying to inject itself dynamically, but AMD wanted to have "works in every game!" as a selling point.
Which would also be fine if they had talked to any of the developers and gotten their "cheat" whitelisted, but they didn't do that. Which is the bizarre part. OK, you have a cool thing you can inject into the game code... but you can't inject anything without bringing developers/anticheat in on the release.
And literally everyone from the most basic modder upwards knows this. Gotta be real, real careful about what you inject into games with anticheat, or you'll eat a ban. Even stuff like reshade is a no-no - it's perfectly harmless, but the anticheat doesn't know that. This is basically "reflex as reshade" and has all the same problems around anticheat.
marketing around half-baked features that get you VAC banned is not really ideal, no. kinda gives the impression that the marketing was given more focus than the product.
it's also a very rookie mistake, like, you have to think it's either someone brand new they hired in, or someone more experienced really dropped the ball on devrel/etc. This is a situation where they absolutely should have known that they should talk to the gamedevs in advance.
At some point you gotta do the thing and ruffle feathers and get/force buy in. I don't see anything inherently wrong with this approach. Shoot first, ask questions later. It's a successful strategy most of the time.
Wrangling all game developers is arguably an impossible task. Building a one size fits all solution is not. Just because it flagged by some anticheat doesn't mean it's failed.
The people whos entire steam collections are worthless with a lifetime VAC ban are just justifiable collateral in the name of a better future? Valve says they'll roll them all back but still
I don't have a particular opinion either way on AMDs approach here (yet), but I'm not sure your comment is making the point that I think you're trying to make.
You start off with:
>The people whos entire steam collections are worthless with a lifetime VAC ban are just justifiable collateral in the name of a better future?
But end with the exact opposite conclusion:
>Valve says they'll roll them all back
So... In the end, no steam libraries are worthless and no one got a VAC ban because of it. It seems like the shoot first and ask questions later approach was somewhat successful again.
> Yes, but, the way their antilag works is identical to a cheat - it's actually hooking/detouring the game's own functions, which any anticheat will see as an obvious hack.
Which is to say that their anticheat system is defective because the method it uses has false positives -- as exemplified by this case, which is not an attempt to cheat.
Is it? The ToS explicitly says that you will be banned if you inject any code into the game or otherwise modify it, and this injects code into the game resulting in bans. To me it seems more like a business choice to not differentiate between harmless mods and cheats rather than a technical issue with the system.
The ToS saying you will be banned even if you don't cheat doesn't make the thing a cheat. You can try to disclaim the harms from your defective anticheat system but that's certainly not the same thing as there not being any.
It's like running across the DMZ. Your intentions don't matter - ALL anticheat will ban you on sight.
You MUST collaborate with the developers to not get banned. This is widely known.
It is expected that _any_ software that does this will be banned, that's how anticheat works. They can't tell what your intentions are and they don't need to.
If AMD worked with valve they wouldn't have to cross the DMZ at all, instead the engine would call the amd driver without any modifications at all.
It's claiming someone cheated when that person did not cheat.
> It's like running across the DMZ.
It's like installing land mines in a residential neighborhood and then blaming the residents for stepping on one. It's not even reasonable if you warn them.
> They can't tell what your intentions are and they don't need to.
They kind of do need to though, because otherwise they punish the innocent. Which is bad. Regardless of whether or not they threaten you with it ahead of time.
> If AMD worked with valve they wouldn't have to cross the DMZ at all, instead the engine would call the amd driver without any modifications at all.
How is that supposed to work with existing games? There are games where the developers no longer even exist but people still play them.
> It's like installing land mines in a residential neighborhood and then blaming the residents for stepping on one. It's not even reasonable if you warn them.
No this is seriously a DMZ. I cannot stress this enough. Seriously any game with anticheat this is an automatic ban. This is not something unexpected whatsoever, this is what anticheat does.
Try this exact same stunt with R6, battlefield, OW, gta, valorant, whatever and you'll get banned almost instantly unless you work with the game developers.
It is very literally anti-cheats job to lay down land mines.
> How is that supposed to work with existing games? There are games where the developers no longer even exist but people still play them.
If there's no anti-cheat there's no problem. If there is anticheat then expect a ban if you try. Anticheat is not mod friendly. You cannot go around modifying the game all you want in online games with anticheat.
> It's claiming someone cheated when that person did not cheat.
This is correct however Anticheat doesn't allow _any_ modifications to the main game code. Seriously test any anticheat in any online game and this will be a ban. There's very, very, very few exceptions ever made to this.
> Which is to say that their anticheat system is defective because the method it uses has false positives -- as exemplified by this case, which is not an attempt to cheat.
This is not a false positive. What AMD did is identical to what cheats do. You cannot modify the game logic without disabling the anticheat period.
Depending on how AMD did it, VAC may not have any idea _what_ modified the game, just that it was modified in an unintended way.
It's not the anti-cheat's job to decide "oh they hijacked the game engine but they're good guys so its okay".
I cannot stress enough that what they did is IDENTICAL to how cheats work, they just happened to be one of the few with innocent intentions which is irrelevant - nobody may tresspass the game logic.
Generally you cannot do this at all - AMD likely won't be whitelisted - valve will add support in-engine instead.
> The anti-lag system is not a cheat. The anti-cheat system thinks it is. By definition, it's a false positive.
Yes but this is not a false positive you fix.
This is a DMZ - you do not cross it no matter what your intentions are. The resolution here will be valve adding in-engine support, and AMD won't modify the game at all.
There is no anti-cheat that will let you cross this DMZ, it's what they do. (technically you could whitelist them but then the drivers become an attack vector).
This is widely known, without collaborating with valve, this is like looking at a mousetrap and knowingly stepping on it barefoot.
To my understanding the graphics drivers modify the rendering pipeline after the draw calls are made, they don't actually hijack code within the game and modify it's logic.
Developers of games add api calls to their game engines for things like antilag/nvidia reflex, that if enabled will notify the driver and allow them to do their thing before returning back to an unmodified game.
You do not modify the internal game state - that's a straight red line.
There's lots of places you _can_ generally hijack, such as the final rendering calls which is how most overlays work.
I don't think whitelisting drivers is common either for the same reason cs2 doesn't allow userland applications to be whitelisted - you can potentially hijack that application instead and then your cheats will be whitelisted.
> Shipping architecture-optimized shader replacements is basically required nowadays.
That's strange to me. Why care at all about what individual games do? A GPU driver includes a shader compiler anyway, why can't it do a good enough job at optimizing the shader for the particular GPU architecture? It's kinda the same reason almost no one writes assembly any more, because modern compilers are so good at generating optimized machine code.
But is it really possible to write a shader that would only perform well on NVidia GPUs? Isn't it like CPUs, where if your code isn't optimal to begin with, it won't run fast, no matter the architecture and compiler optimizations?
GPUs are much more architecturally diverse than CPUs so yes, that’s exactly the case that different codes are required for optimal performance on different hardware.
From the game's perspective this was a cheat. The anti-cheats job is to make sure nobody tresspasses with the game logic.
They modified where methods returned to so they could run their own code before returning to the game.
VAC cannot determine if this was a bhop-wallhack or an anti-lag feature.
It just sees that someone modified the game.
This is like walking up to someone's building and spray painting a mural without permission. No matter how innocent or well intentioned it is - internal modification is a red line.
So yes it is a false positive, but it's not the type VAC is concerned about.
What AMD did was like crossing the DMZ. It doesn't matter who you are or what your intentions are. It's not possible for normal applications to do this unless they're specifically trying to.
You cannot cross the DMZ without special permission, and even then it's more likely valve adds it directly to the engine instead.
There's more "accidental" type of detections which would be false positives too - but this is a clear line in the sand AMD crossed.
---
There is no anti-cheat that will let you do this. You contact valve and work with them to add support in engine. What AMD did was insane.
I am not a CS player though I spent several hours with the game. While it plays much better than CS:Go, it stutters surprisingly often for the first few minutes, even on my 5800x3d/6800xt machine. Despite the 300 FPS.
Shit happens and will be fixed. Still better than splitting the community. They need to work with AMD and resolve the issue.
The game runs unplayably poorly on some people's hardware, Valve's own Steam Deck included (doesn't even reach 60fps in menus on lowest settings). macOS users also had their game taken away with no replacement promised. That's at least two groups of people who could play CS:GO fine in the recent past, but can no longer play a modern CS game.
It amounts to waiting until just before vsync to start rendering a frame CPU side, in the hope that the frame is fresher than what you would get from a scattergun ‘mailbox’ approach aka vsync disabled
It should theoretically be possible to get the tear-free smoothness of vsync combined with even lower latency than vsync disabled, but in reality is it is difficult to predict how long a frame will take to render
It’s not clear how they solved this, or why it required hooking into games more than graphics drivers already do
In the event that the CPU is faster than the GPU, the CPU run ahead of the GPU and queue multiple frames to render, regardless of adaptive sync or not. This adds lag. Adaptive sync or high Hz only gets rid of up to one frame of delay from vsync timing, not delay from excess frame queuing.
What Anti-Lag does is throttle the CPU work to reduce this delay to as low as sub-frame, so it doesn't process input and begin frame processing until closer to display time -- so the game starts frame updates with fresher input and gets those frames out with less delay. Graphics APIs often only allow setting the frame queue length in an integer number of frames and it can be difficult to reliably tell when frames present and control frame queuing, especially with a compositor involved. This has the graphics driver involved, so it knows the absolute truth of when frames hit the output.
> the CPU run ahead of the GPU and queue multiple frames to render
Wouldn't the game limit that to 2-3 frames at most?
> Graphics APIs often only allow setting the frame queue length in an integer number of frames and it can be difficult to reliably tell when frames present and control frame queuing, especially with a compositor involved.
I'm pretty sure you can control the swap chain using DXGI:
> Use DXGI 1.3 to reduce the effective frame latency by waiting for the swap chain to signal the appropriate time to begin rendering a new frame.
It isn't just CS2. Apex Legends has players affected by this. Respawn Entertainment has addressed it and said is reverting bans. I guess part of the issue is an AMD update made it default on, so players who didn't even know it got included were affected.
61 comments
[ 4.6 ms ] story [ 126 ms ] threadAMD literally made an "internal cheat" for cs2. This is a widely known guaranteed ban and likely among most people (if you modify the game engine then you get banned). Even with weak anticheat like VAC.
This means AMD didn't work with valve at all on this feature, a feature I assume both parties would be interested in. This would be one of the biggest esport games for the anti-lag feature that amd could advertise as supporting.
On top of not contacting valve, they had the expertise to do this, but somehow didn't realize they would get banned?
Somewhat hilariously there's no way they did this for valorant - that game wont even launch if you have debug tools open (unless amd is so dense they worked around that).
This is the third false-VAC since the cs2 beta. First was a unprotected yaw command (no commands should get you vacced unless they're protected by sv_cheats), windows 7 users, and now amd anti-lag+.
Although in the case of AMD, this is definitely not valve's fault. They detected exactly what they're supposed to.
reflex and antilag basically work by flipping the vsync model around. instead of "render a frame -> wait for the monitor to be ready to draw", it's "wait -> render". And by dynamically adjusting the wait time, you can have the frame ready at the last possible moment before the monitor is ready. This means game state is $WAIT_TIME milliseconds fresher, and you've reduced latency by that amount.
well, that means you have to have some method to control when the game starts doing the game loop. So you have to be inside the engine somehow - either you have a WAIT_FOR_REFLEX() in the code, or you grab control of the frame queue and don't return control until you're ready, and you just block until the right moment.
AMD injected that part.
I’m very interested to know what they did beyond standard low latency frame scheduling, and why it required hooking into games to the point of triggering anti cheat
isn't this pretty much exactly what graphics drivers have been for years now though? game-specific behavior, day-one driver updates, and all that. the only (unfortunately) novel thing here is doing this without the express consent and cooperation of the game's developer.
Nvidia did it "properly" and worked with valve to develop it in-engine. I could definitely be wrong but I think many of the game-specific optimizations have to to with how they handle the draw-calls, not modifying the actual games themselves.
The ban system detects the method, not the effect and certainly not the motive.
[1] https://github.com/microsoft/Detours
Reading yes (antivirus).
Writing no, that's rare and generally purposeful.
I have no idea what processes you have that do that unless they're specialty tools like reshade, autohotkey, etc.
Programs do hook the screen for the overlay but that's outside of the game's logic.
It's not at all unusual.
You would have to be manually looking for it then? Also if you do this to the main engine.dll you WILL be banned.
Most of the things you're mentioning you wouldn't hook the main engine.dll, you'd be hooking the system api's, directx, etc.
I'm not sure many people commenting here play competitive games, it's a ruthless cat-mouse war with cheaters. Anticheat is NOT friendly to modding any of the game code. Yes some anti-cheats will ban you for use autohotkey.
From my understanding the newer api's have built in methods to negotiate these optimizations.
And the gpu driver is free to do whatever it likes after the api calls.
So the game tells the driver what to render, which they can reorder/optimize/modify/cache/compile as they like.
What they can't do is hijack the game, and modify it's internal logic.
NVIDIA's Reflex actually requires that it be integrated into the game code by developers (which they then provide) rather than trying to inject itself dynamically, but AMD wanted to have "works in every game!" as a selling point.
Which would also be fine if they had talked to any of the developers and gotten their "cheat" whitelisted, but they didn't do that. Which is the bizarre part. OK, you have a cool thing you can inject into the game code... but you can't inject anything without bringing developers/anticheat in on the release.
And literally everyone from the most basic modder upwards knows this. Gotta be real, real careful about what you inject into games with anticheat, or you'll eat a ban. Even stuff like reshade is a no-no - it's perfectly harmless, but the anticheat doesn't know that. This is basically "reflex as reshade" and has all the same problems around anticheat.
you make it sound like this is a bad thing?
it's also a very rookie mistake, like, you have to think it's either someone brand new they hired in, or someone more experienced really dropped the ball on devrel/etc. This is a situation where they absolutely should have known that they should talk to the gamedevs in advance.
Wrangling all game developers is arguably an impossible task. Building a one size fits all solution is not. Just because it flagged by some anticheat doesn't mean it's failed.
You start off with:
>The people whos entire steam collections are worthless with a lifetime VAC ban are just justifiable collateral in the name of a better future?
But end with the exact opposite conclusion:
>Valve says they'll roll them all back
So... In the end, no steam libraries are worthless and no one got a VAC ban because of it. It seems like the shoot first and ask questions later approach was somewhat successful again.
Which is to say that their anticheat system is defective because the method it uses has false positives -- as exemplified by this case, which is not an attempt to cheat.
Is it? The ToS explicitly says that you will be banned if you inject any code into the game or otherwise modify it, and this injects code into the game resulting in bans. To me it seems more like a business choice to not differentiate between harmless mods and cheats rather than a technical issue with the system.
It's like running across the DMZ. Your intentions don't matter - ALL anticheat will ban you on sight.
You MUST collaborate with the developers to not get banned. This is widely known.
It is expected that _any_ software that does this will be banned, that's how anticheat works. They can't tell what your intentions are and they don't need to.
If AMD worked with valve they wouldn't have to cross the DMZ at all, instead the engine would call the amd driver without any modifications at all.
It's claiming someone cheated when that person did not cheat.
> It's like running across the DMZ.
It's like installing land mines in a residential neighborhood and then blaming the residents for stepping on one. It's not even reasonable if you warn them.
> They can't tell what your intentions are and they don't need to.
They kind of do need to though, because otherwise they punish the innocent. Which is bad. Regardless of whether or not they threaten you with it ahead of time.
> If AMD worked with valve they wouldn't have to cross the DMZ at all, instead the engine would call the amd driver without any modifications at all.
How is that supposed to work with existing games? There are games where the developers no longer even exist but people still play them.
No this is seriously a DMZ. I cannot stress this enough. Seriously any game with anticheat this is an automatic ban. This is not something unexpected whatsoever, this is what anticheat does.
Try this exact same stunt with R6, battlefield, OW, gta, valorant, whatever and you'll get banned almost instantly unless you work with the game developers.
It is very literally anti-cheats job to lay down land mines.
> How is that supposed to work with existing games? There are games where the developers no longer even exist but people still play them.
If there's no anti-cheat there's no problem. If there is anticheat then expect a ban if you try. Anticheat is not mod friendly. You cannot go around modifying the game all you want in online games with anticheat.
> It's claiming someone cheated when that person did not cheat.
This is correct however Anticheat doesn't allow _any_ modifications to the main game code. Seriously test any anticheat in any online game and this will be a ban. There's very, very, very few exceptions ever made to this.
This is not a false positive. What AMD did is identical to what cheats do. You cannot modify the game logic without disabling the anticheat period.
Depending on how AMD did it, VAC may not have any idea _what_ modified the game, just that it was modified in an unintended way.
It's not the anti-cheat's job to decide "oh they hijacked the game engine but they're good guys so its okay".
I cannot stress enough that what they did is IDENTICAL to how cheats work, they just happened to be one of the few with innocent intentions which is irrelevant - nobody may tresspass the game logic.
Generally you cannot do this at all - AMD likely won't be whitelisted - valve will add support in-engine instead.
The anti-lag system is not a cheat. The anti-cheat system thinks it is. By definition, it's a false positive.
Yes but this is not a false positive you fix.
This is a DMZ - you do not cross it no matter what your intentions are. The resolution here will be valve adding in-engine support, and AMD won't modify the game at all.
There is no anti-cheat that will let you cross this DMZ, it's what they do. (technically you could whitelist them but then the drivers become an attack vector).
This is widely known, without collaborating with valve, this is like looking at a mousetrap and knowingly stepping on it barefoot.
It's a feature of the GPU and driver not the game.
Developers of games add api calls to their game engines for things like antilag/nvidia reflex, that if enabled will notify the driver and allow them to do their thing before returning back to an unmodified game.
You do not modify the internal game state - that's a straight red line.
There's lots of places you _can_ generally hijack, such as the final rendering calls which is how most overlays work.
I don't think whitelisting drivers is common either for the same reason cs2 doesn't allow userland applications to be whitelisted - you can potentially hijack that application instead and then your cheats will be whitelisted.
That's strange to me. Why care at all about what individual games do? A GPU driver includes a shader compiler anyway, why can't it do a good enough job at optimizing the shader for the particular GPU architecture? It's kinda the same reason almost no one writes assembly any more, because modern compilers are so good at generating optimized machine code.
They modified where methods returned to so they could run their own code before returning to the game.
VAC cannot determine if this was a bhop-wallhack or an anti-lag feature.
It just sees that someone modified the game.
This is like walking up to someone's building and spray painting a mural without permission. No matter how innocent or well intentioned it is - internal modification is a red line.
What AMD did was like crossing the DMZ. It doesn't matter who you are or what your intentions are. It's not possible for normal applications to do this unless they're specifically trying to.
You cannot cross the DMZ without special permission, and even then it's more likely valve adds it directly to the engine instead.
There's more "accidental" type of detections which would be false positives too - but this is a clear line in the sand AMD crossed.
---
There is no anti-cheat that will let you do this. You contact valve and work with them to add support in engine. What AMD did was insane.
Shit happens and will be fixed. Still better than splitting the community. They need to work with AMD and resolve the issue.
I'm guessing a scheduling thing, but have absolutely no data. This is on Fedora Linux with a very recent kernel, Mesa, and gamescope
It should theoretically be possible to get the tear-free smoothness of vsync combined with even lower latency than vsync disabled, but in reality is it is difficult to predict how long a frame will take to render
It’s not clear how they solved this, or why it required hooking into games more than graphics drivers already do
If you don't underestimate the render time (and miss the refresh) then the frame will be fresher.
What Anti-Lag does is throttle the CPU work to reduce this delay to as low as sub-frame, so it doesn't process input and begin frame processing until closer to display time -- so the game starts frame updates with fresher input and gets those frames out with less delay. Graphics APIs often only allow setting the frame queue length in an integer number of frames and it can be difficult to reliably tell when frames present and control frame queuing, especially with a compositor involved. This has the graphics driver involved, so it knows the absolute truth of when frames hit the output.
Wouldn't the game limit that to 2-3 frames at most?
> Graphics APIs often only allow setting the frame queue length in an integer number of frames and it can be difficult to reliably tell when frames present and control frame queuing, especially with a compositor involved.
I'm pretty sure you can control the swap chain using DXGI:
> Use DXGI 1.3 to reduce the effective frame latency by waiting for the swap chain to signal the appropriate time to begin rendering a new frame.
https://learn.microsoft.com/en-us/windows/uwp/gaming/reduce-...