Just watching this now. Looks like the new PresentMon update has a new metric called GPU Busy, and Intel is going to keep adding more metrics. Looks like we'll start seeing new metrics in reviews. Basically measures how much time the GPU spends rendering per frame, so you can see what percentage of the frametime the gpu was busy.
Hardware reviews - PresentMon Update, GPU Busy
- Thread starter Scott_Arm
- Start date
Just watching this now. Looks like the new PresentMon update has a new metric called GPU Busy, and Intel is going to keep adding more metrics. Looks like we'll start seeing new metrics in reviews. Basically measures how much time the GPU spends rendering per frame, so you can see what percentage of the frametime the gpu was busy.
The GPU expectation is 40% IIRC for games? 60% at the high.
With these metrics being captured for all games now, I am going to be very interested in the standard. I think we will see a huge variation from the games here. But of course testing the same game we will see how well the GPUs are being used.
Finished watching. This basically seems very similar to capframex in some ways. I'm pretty sure capframex has it's own libraries that can take advantage of nvidia, amd, intel telemetry. Haven't looked at it in a while, so I'm not sure exactly what it's capable of.
I'm also curious about the difference between this GPU Busy metric and the typical GPU Usage we see. I know GPU Busy is measure in time, and GPU Usage is a percentage. Does GPU Busy / Frame Time * 100 = GPU Usage? How exactly has GPU Usage been estimated or calculated to this point in time?
I'm also curious about the difference between this GPU Busy metric and the typical GPU Usage we see. I know GPU Busy is measure in time, and GPU Usage is a percentage. Does GPU Busy / Frame Time * 100 = GPU Usage? How exactly has GPU Usage been estimated or calculated to this point in time?
Well, looks like there's not really an overlap. Cool stuff.
Last edited:
I installed. It's very nice. Disabled the geforce overlay, so I'm running out of reasons to need geforce experience.
You can set the application to windowed mode, so instead of an overlay you have a window you can drag to a second monitor. That's definitely better. I can put more info on it and move it away and only look at it if I need to. Seems to be able to detect running applications okay if you start it up after you've already started your game.
What I'm kind of not understanding is why GPU Busy is any better than the GPU Usage metric we already had. Any time GPU busy has a delta from the frame time GPU usage is also low. I'd say I prefer to have it running than an overlay.
You can set the application to windowed mode, so instead of an overlay you have a window you can drag to a second monitor. That's definitely better. I can put more info on it and move it away and only look at it if I need to. Seems to be able to detect running applications okay if you start it up after you've already started your game.
What I'm kind of not understanding is why GPU Busy is any better than the GPU Usage metric we already had. Any time GPU busy has a delta from the frame time GPU usage is also low. I'd say I prefer to have it running than an overlay.
hypothesis: If Frame time on this graph is only specific to the GPU parts and not the CPU parts -- then GPU busy versus frame time actually tells you how idle the GPU is and I suppose the goal is to get GPU busy as close to frame time as much as possible. GPU utilization however, which is over 98% is the metric we know in which the GPU has received draw calls to do work, but not an actual indication of work done. The GPU it utilized even if it's waiting.
Very cool. Also, judging by the GN video, it sounds from Tom like in the future we could potentially be able to see what exactly is causing the stalls, and how much time it's taking. So we could potentially have a very clear understanding of whether stutters are compilation related, or for some other reason.
Yah, it sounds like they want it almost to be like a profiler that gives you hints about bottlenecks. That will be very cool.
It's not, it's just a different way of viewing GPU usage (ms instead of %) which allows you to subtract it from frametime and get something which GPU usage wouldn't provide - the amount of time a frame has spent outside of the GPU.
Now what that amount would tell you is the more interesting question. From what I've seen it doesn't exactly tell the end user much at the moment since the "wait" is a "black box" and the time outside of GPU busy can also be due to the game's logic and renderer, not necessarily the API or the driver (aka "wait" part). So as of right now knowing that time alone doesn't exactly help. Maybe it will in the future if we will be able to have a peek at what this time is comprised of.
I think it's also worth mentioning that this won't help with figuring out "broken games" much if said games are broken in their GPU optimization part. The example someone gave already is a GPU which is at 100% usage but consume ~50% of its peak power - this means that the shaders this GPU is running isn't using the GPU h/w properly and has nothing to do with the CPU side of rendering process, so the "GPU busy" here would also be close to frametime as if there is nothing wrong.
Just wanted to comment that this is a really bad conclusion in general. Using more GPU power does not mean you are doing anything more "properly" or "efficiently" and vice versa. Even more than with CPUs you can write a trivial loop to suck GPU power (see Furmark) or conversely really efficient code can use small, power-efficient parts of the GPU. Ultimately there's no objective metric for "efficiency" in rendering - you have to judge your personal opinion of the quality of output against how many resources it is taking on your machine.
Never said that.
What I've said is that when you see a 99% GPU utilization with it consuming 1/2 of its peak power then the code is highly likely to be putting the GPU into a constant wait or flush which is a good indication of it not being optimized properly for that GPU.
You obviously can't assume that a code is 100% optimal if it's using 99% of GPU at peak power.
On a related note: RTSS adds PresentMon as an information source.
So you can put "GPU Busy" from PresentMon onto your RTSS overlay now if you wish.
There are also some musings on PresentMon from Alexey through the link.
Last edited:
Right, I don't agree with that. The power swings of various legitimate workloads on GPUs are huge depending on what is happening. Something that slams primarily the rasterizer and depth hardware for instance will use a small amount of power compared to something slamming memory and ALU, but the two are not interchangeable. Sometimes you can overlap different things, but not always. Certainly 1/2 peak power is not even close to a threshold I would consider meaningful. I suspect in many cases with some tuning you could actually get nearly the same experience with 1/2 the GPU power on many games.
If you really want to understand what's going on there is no substitute for getting out proper profiling tools. There are limits to how far these system-level metrics can inform things, although GPU Busy is certainly a generally useful one. I'm a bit skeptical about the utility of things that try to infer specific problems from the outside as these are both limited by not having proper instrumentation in shipping titles, and fundamentally not actionable by users anyways. Balance of CPU/GPU is at least something that is useful information to consumers.
I'd say that most of the time you should be able to overlap and if you can't then we're back at the original point of the code not being optimized properly.
We can imagine a large number of "legitimate" (whatever that means) workloads which would only stress one part of the GPU pipeline but if you're building a modern game with only that workload being in your renderer then you probably not building the renderer properly and may in fact look at other options of implementing the same workload. Case in point - Nanite.
I haven't finished watching the entire thing yet either, but I have some immediate thoughts.
Yes, it's extremely useful to have deeper insights to what exactly the CPU and GPU are doing to generate/display a frame.. but I'm wondering how useful it is in the context of GPU/CPU reviews. It seems to me like having access to more information just gives people more data with which they can interpret and form the wrong conclusions from.
I think at a certain point, you're needlessly complicating the review process. Unless they have some very clear and concise way of displaying this data which is easy to understand and hard to misinterpret. I can see posts from gamers now pointing to reviews like this and blaming devs for x and y with more confidence than ever.
Hope I'm wrong.
After finishing watching I feel the same way. You'll be able to measure stuttering directly, but you won't have information to understand what's causing the stuttering. I think for overclockings it could be good, or competitive gamers. Overclocking can sometimes work but introduce stuttering without crashing. The fps numbers are bigger, but the experience is worse. For competitive gamers, you can hyper tweak settings to get optimal settings to minimize stutters while still keeping your gpu busy enough. You'll be able to directly see whether being cpu or gpu limited provides a smoother experience. In terms of a gpu review, I guess you could see if there are differences between stuttering in a variety of games depending on gpu vendor and driver, but I actually doubt there are big differences ... but I guess we'll see. I am curious to see if it helps with cpu benchmarks. I would be interesting to see how RAM latency, cache etc affect stuttering.
And if I did what could I actually do about it - bugger all I suspect
Release 2.0.0 · GameTechDev/PresentMon
New Features The majority of metrics are changed to use the time that the CPU started working on a frame as the reference point instead of the present() call, with values that are more aligned to...
github.com
@Dictator
Release 2.0.0 · GameTechDev/PresentMon
New Features The majority of metrics are changed to use the time that the CPU started working on a frame as the reference point instead of the present() call, with values that are more aligned to...
Similar threads
