- cross-posted to:
- hardware@hardware.watch
- cross-posted to:
- hardware@hardware.watch
You must log in or register to comment.
It’s quite sad that even after all his videos, he still have to remind people that running GPU at 99% usage increases input latency, and majority of PC gamers still say it’s not true. What about not creating the problem in the first place, so you don’t need all those Anti-Lag and Reflex?
I don’t get what is even going on with amd anymore. Should I just return my 7900XT? Is it just a total piece of shit? Everything I see on the internet is just saying why I should be regretting my purchase and that I made a mistake not going nvidia
Why did you buy it over Nvidia in the first place? Are those reasons and needs being fulfilled and does it meet your expectation for what you paid for it? If so, then why are you regretting your purchase? If you like it, if it does what YOU want it to do, then you shouldn’t regret it.
If you are happy with your purchase who cares what anyone else thinks. It’s all just redditors engaging in console war behavior. It will happen now and will still happen for decades to come.
If you are not happy with your purchase then buy an NVIDIA card. It really does not matter at the end of the day who gets your money or which redditor is right or wrong what matters is if you are happy with your purchase.
Okay so i have a few questions First, why AMD didn’t go the same approach as nvidia and added an SDK so game devs could add it into their game? Second, why did AMD lock it to RDNA3 Gpus while Reflex is usable from 900 series and up? And thirdly, why is reflex proprietary to nvidia since it’s a software solution(A dynamic frame limiter) ? Correct me if i am wrong
still waiting for RDNA2 support…
to sum it up AMD can totally add support for anti-lag+ if they do it properly for all gpu’s
AAH, wtf is this intro sound?
aside from the antilag stuff:
this is an excellent visual representation of CPU & GPU bottlenecks. what they are and how it occurs.
most people don’t understand it well enough
The problem is that it’s not technically correct. GPU can’t bottleneck CPU because the pipeline goes one way. Nothing prevents CPU from drawing as much frames at it wants. What happens in the most game engines - the engine checks if GPU is ready to accept another frame, and if it’s not, it tells CPU to chill a bit, but not all games do that properly - i.e. in NFS Undercover rendering thread sticks to 100% at all times, at least did last time I checked. Saying “GPU bound” is more technically correct, as bottleneck implies that there is some other PC part down the pipeline, which isn’t the case for GPU - GPU is the last part. But I’m just being pedantic here; objectively - Battle(non)sense ineed does a great job at explaining things to people in simple terms.
It’s more complicated than that. Yes, the physical pipeline ends at the GPU since the frame just sits in the GPU until the OS is ready to present it, but the logical pipeline loops back to the CPU since the CPU then moves on to the next frame in the render queue which may or may not be available. Ideally it would simply be available as the GPU has finished rendering that frame and the OS has finished presenting that frame which gives the CPU free reign over it, but it may be in a present-pending state where it’s waiting for the OS to present it or it may be in a currently-rendering state where the GPU is actively rendering it.
If the frame is in a currently-rendering state then the CPU cannot use that frame since that frame’s resources are being actively used by the GPU and trying to access those resources leads to a very bad time, so the CPU has to try another frame. If the frame is in a present-pending state then the CPU can use it so long as vsync is disabled and screen tearing is acceptable, as that frame’s resources aren’t being actively used anymore and the OS generally allows reusing a present-pending frame (after all, that’s why vsync is typically an option and not mandatory).
If the CPU is sufficiently far ahead of the GPU then it will always eventually hit a wall where it tries to use a currently-rendering frame, has no other frames it can use and is forced to sit idle. If you’re on newer APIs such as Vulkan or DirectX 12 then you can bypass this somewhat by using the mailbox presentation mode (not sure what the name is under DirectX 12, but that’s the name under Vulkan) to at least tell the OS that you intend on ping-ponging between two different frames in a triple-buffer setup, which lets the CPU ping-pong between those two frames while the GPU is busy rendering its currently-rendering frame. Things get exponentially more complicated under DirectX 12 and Vulkan, however, as the engine itself is now responsible for building and managing the render queue, the API/driver/OS just handles the presentation side of things.
This raises some questions.
- What do you mean by “frame may not be available” for CPU? I assumed CPU creates frames. And then “CPU cannot use that frame”. Did you mean to say “frame buffer”?
- What do you mean by “frame’s resources”?
- Isn’t “the wall” render queue limit typically?
- I guess mailbox presentation mode is LIFO-queued triple buffering. What you described sound like CPU is filling frame buffers with some data that might or might not be later used by GPU, but I assumed it’s GPU that creates and fills frame buffers with data. Are you sure it has anything to do with CPU’s job?
- In unlocked framerate with no VSync scenario, when GPU is at 99% usage - in most games CPU usage reduces, as render queue is full. It, however, is not the case for some games, like NFS Undercover. How specifically does this process happen in such scenario, or what tells CPU to wait instead of drawing more frames?
What do you mean by “frame may not be available” for CPU? I assumed CPU creates frames. And then “CPU cannot use that frame”. Did you mean to say “frame buffer”?
I meant the render queue, of which the framebuffer/swapchain is part of.
What do you mean by “frame’s resources”?
In this case I mean GPU resources that the CPU may need to access. Think uniform buffers that pipe game state information to the shaders, textures that hold animations that update each frame, vertex/index buffers that hold mesh data that updates each frame, etc. Each frame typically has to be given its own set of these resources so that when the CPU updating the resources for frame N doesn’t change or potentially corrupt the resources that the GPU is actively using for frame N-1.
Isn’t “the wall” render queue limit typically?
Yes and no, depends on how well the CPU and GPU stay in sync with each other.
I guess mailbox presentation mode is LIFO-queued triple buffering. What you described sound like CPU is filling frame buffers with some data that might or might not be later used by GPU, but I assumed it’s GPU that creates and fills frame buffers with data. Are you sure it has anything to do with CPU’s job?
Yes, since it basically lets the CPU bounce between two available/present-pending frames while it waits for a currently-rendering frame to clear. This way the CPU never sits idle, it’s just constantly overwriting previously recorded command lists and previously updated resources that haven’t been picked up by the GPU yet.
In unlocked framerate with no VSync scenario, when GPU is at 99% usage - in most games CPU usage reduces, as render queue is full. It, however, is not the case for some games, like NFS Undercover. How specifically does this process happen in such scenario, or what tells CPU to wait instead of drawing more frames?
Normally it’s an API/system call that tells the render queue to present the current frame and swap to the next frame that tells the CPU to wait. In older APIs it’s a lot more nebulous so I can’t tell you exactly why NFS Undercover does that, but my guess would be that the CPU and GPU are close enough to not exhaust the render queue quickly or the API is detecting that some usage pattern lets the CPU access in-use resources by the GPU in some places in the pipeline.
Thanks for taking your time to explain all this!
No problem. I left out some of the more complicated details and simplified others so if you want to learn more I’d recommend looking into how Vulkan’s command buffers, device queues, fence/semaphore resources work which are all part of the logical side of the render queue, as well as how Vulkan’s swapchain works for the frame presentation side of the render queue. Vulkan and DirectX 12 both expose quite a lot of how the render queue works so they can shed some light on what the driver is having to do behind the scenes for DirectX 11 and OpenGL.
First they force it, when no one wants it, make it open so they can proclaim to care about users.
It’s AMD modus operandi latelyAm I the only one who doesn’t really give a shit about these technologies? I’ve never noticed an input lag difference this small.
I remember AntiLag+, it went away much faster than it came.
Went away without lag
BattleNonSense is back?
Latency added to the list of things Radeon users don’t care about. List also includes upscaling, graphics, efficiency, crack software backing, being competitive
List of things they do care about: COD fps numbers, pretending like they get more value per dollar so they can sit on their high horse over the uninformed pleb, Su-bae
Things I don’t care about: Ray Tracing (mostly, maybe in a few years it will be vital), Frame Generation (misnomer, actually fancy motion blur). Things I do care about: Upscaling (I use this in every game that features it, and generally think FSR2 looks pretty good), Latency (antilag+ needs to be reenabled asap), Power usage(I used to care more but I moved my pc into a cooler room).
Obviously we get more value per dollar… ah nm you’re just a troll.
Obviously we get more value per dollar
Now consider EU electricity prices, 7900 XTX can draw up to 100w more than 4080 (same tier competitor).
Lets say u use card gaming 20 hours a week (insane numbers for some, extremely low for most gamers here on reddit), 80w extra power draw, 0.4 euro per kwh in Europe (Denmark i think easily hits 0.5 euro per kwh tho for example).
Thats 33 euro per year more to run XTX. Bump it to 40 hours a week (again, depends on the user but still far from what some play), thats 66 euro per year extra.
XTX is like 80 euro cheaper than 4080 in my country atm. It rather quickly becomes more expensive card. And theres the idle draw bug, which to this day happens on my SO system, where her desktop draws 100w idle on 7900XT. Never been so disapointed with a card (we didnt plan or want to buy XT but it was spontaneous decision before christmas to buy her new GPU to enjoy some new games and there wasnt much choice in physical store before christmas).This is some pretty cringe cope
Lets be honest. Buying AMD is like taking an L.
tldr?
Anti-Lag+ is a cool tech and it works well. The problem was obviously the lack of communication with developers which could have prevented it from triggering anticheat.
It’s not an issue of communication. It’s a fundamental flaw with their implementation which needs to be addressed.
it works as intended. it allows a very broad range of games to easily support it. but they absolutely need to make it so that devs don’t trigger anti-cheat if it is turned on.
No, AMD didn’t intend to get users banned and for the feature to be useless for multiplayer games. That’s why AMD was caught by surprise and had to remove it.