I was trying to reach out Rob´s experience that i cannot "trust"  the GPUload statement from ProcessExplorer

 

It's not a matter of "trust" ... it's a matter of finding out exactly what it is measuring to come up with a single GPU load %.  Until you know exactly how it's determining that value, one can't really formulate an opinion. 

 

Also, can't really make an association between GPU temps and work loads ... DX9 is different from DX10 which is different from DX11 ... DX9 and FSX could simply be making the GPU do more "less efficient" work.  Sorta like having a CPU in a tight loop where all it does is just increment a value (X += 1) ... CPU will heat up and register as doing "a lot of work", but it's not accomplishing much.  So you really can't use GPU temps as a measure or work load.

 

There are tools to measure more specific GPU performance/usage, these are usually provided by the manufacturer (i.e. nVidia) that you can integrate into the source code for profiling performance.

 

I'm not say the GPU % value or temp values are useless, it's just not something I would use to make any conclusions or come up with theories.

 

Cheers, Rob.

Thanks Rob

 

Everyone free to help try gate 54 at CYVR with FSDT facing Northeast,then right 120 and south 210 and then over water at 300. What are your FPS in the bonanza?

 

Thanks

 

Michael

Most of these RT GPU monitoring apps have their origin  from Alexey Nicolaychuk aka Unwinder, the creator of RivaTuner. They monitor and display a variety of GPU usage stats and I have never read any serious critique of the approach being inaccurate.

 

 

They monitor and display a variety of GPU usage stats and I have never read any serious critique of the approach being inaccurate.

 

I'm not suggesting it's inaccurate ... can't make a determination until it's known what exactly is being measured and how it's deriving a single "load %" value.  GPU does a lot of different kinds of processing.

Maybe the driver is broken from Nvidia?

 

I actually see no performance impact changing the settings in P3DV2 . Resolution Max autogen ,Water maxed out (look cool)shadows on -off etc. Maybe its related to the time of day ?

 

The best FPS i have achieved is actually around CYVR from FSDT where the GPULOAD is rising to 75-85% . FPS is here around 35-60fps(60fps facing the water) on ground in the Carenado Bonanza. 

 

Hmm well for now its back to FSX doing some IFR. Will be back later with some VFR. ASN works like a charm now btw.

 

Michael

I see similar issues Michael and don't have good explanations other than that it appears to me 2.2 gets CPU bound much quicker than 2.0 or 2.1, at least that's what appears to be happening when I see CPU usage pegged at 100% on the main thread, GPU utilization at a modest level of 50-70% (GPUz).  I can change all sorts of settings in 2.2 and frame rate stays the same.   I can up specific sliders and make the GPU use go up to 100%--unfortunately visual differences are so subtle while make the GPU work more, that once again as w/ FSX the CPU starts appearing to be the limiter most of the time in complex scenarios.  OTOH, some are saying SLI w/ the dev mode executable (or whatever it is) is making a substantial difference, which lends credence to Rob's argument that you can't always trust the GPU utilization reported value.  

Me too happens to me, I have two GTX 780 in SLI (I know, SLI is not yet enabled prepar3Dv2) but dropped dramatically to the v2.2 of FPS, I have the FTX GLOBAL, VECTOR, 2 MEGAAIPORTS, REX and REX4, and before I did not lose 45, 60 fps, with slippers near maximum, if bottleneck, as it can be avoided?

Same same sans the SLI.  Something's changed big time in 2.2 and to me it is not all good.  If you could completely disable cloud shadows and return to 2.1 performance behavior it might be defensible, but I'm not sure that's the case--seems you can disable cloud shadows and the, what appears to be CPU limited behavior ensues, much more so than in 2.1 or so it seems.   I took off out of KSMF, a quite easy to handle area previously in FSX or P3D V2, in the RA Duke and see frames of 24 at point blank range from a gate--in FTX NCA yes, but still.   Prior to 2.2 I could easily fly in and out of this region in the QW757 but now perf is not good at all really.  I think we're going to see another patch address some of this behavior.

 

 

OTOH, some are saying SLI w/ the dev mode executable (or whatever it is) is making a substantial difference, which lends credence to Rob's argument that you can't always trust the GPU utilization reported value.

 

I can move sliders up/down and around, doesn't change the GPU % load value at all ... usually 20-25% range regardless ... so whatever these tools "measure" it doesn't appear to be working for me.

 

But the programmer in me will always say, don't make assumptions without knowledge of what's actually happening.  Probably because over the years my assumptions have done nothing positive for my programming efficiency -- I don't even trust documentation these days, always try it and see how it really works.  I use documentation as a guide of "how it's supposed to work", and then verify how it "really" works.

 

Cheers, Rob.

I'm not suggesting it's inaccurate ... can't make a determination until it's known what exactly is being measured and how it's deriving a single "load %" value.  GPU does a lot of different kinds of processing.

 

https://devtalk.nvidia.com/default/topic/486122/cuda-programming-and-performance/something-like-34-top-34-to-monitor-the-gpu-/

 

Obviously, there isn't a GPU usage sensor, so it is done by algorithm.

https://devtalk.nvidia.com/default/topic/486122/cuda-programming-and-performance/something-like-34-top-34-to-monitor-the-gpu-/

 

Obviously, there isn't a GPU usage sensor, so it is done by algorithm.

 

Thanks for the link.  If accurate, it's what I feared it's using.  It's an older thread (2011) but this person's request is spot on as to what's is needed to get some idea of actual GPU load:

 

 

Let us say multiple GPU APPs are running, the "TOP" utility shows only the CPU usage of the processes.

 

Even when a GPU App is sleeping, the kernels spawned by it could be actively running on the GPU.

 

So, what "Top" shows is completely irrelevant for us.

 

It would be very good to see what actual kernel is running on the GPU. Only the driver can tell that.

 

If NVIDIA can tell us info on

 

1. How many STREAMS are present?

 

2. PID or THREAD ID associated with each STREAM

 

3. Pending Kernel Launches on each queue (would be good to show other operations like memcopy as well)

 

4. Name of GPU Kernel(s) that is(are) currently running

 

What this user is asking for is far more meaningful than a "busy" signal.

 

Cheers, Rob.

My impression from following various "GPU usage monitoring" topics on places like Tom's Hardware and Guru of 3D, is that the algorithm that is used in these various RT monitoring apps is based on a balance of accuracy and overhead. Most users apparently want an "idiot light" equivalent for GPU usage. And any GPU usage calculation that is too elaborate might cut into performance.

 

You could always post something to Unwinder in his Riva Tuner forum and ask him. He seems like a likable fellow ... sort of the "Snave" of GPU gurus. :He He:

I can move sliders up/down and around, doesn't change the GPU % load value at all ... usually 20-25% range regardless ... so whatever these tools "measure" it doesn't appear to be working for me.

 

I can fully attest GPU-z's sensors clearly reflect changes in sliders, in particular shadow quality, shadow cast/receive, etc.  It's very simple to go from 40% to 100% w/ the right sliders/box settings, which would be predicted in a monitoring algorithm that aptly reflects the GPU reaching its computing limits at every moment in time.  I can see the idea of computing demand not necessarily progressing consistently but rather in fits and starts and so capturing a meaningful average or what have you would be a challenge.  OTOH flight sim most often sends a, I would imagine, quite steady stream of tasks and so that may mitigate this issue enough to call the right algorithms valid.

 

 

I can fully attest GPU-z's sensors clearly reflect changes in sliders,

 

But I've also seen what Rob is describing, where you increase a slider a notch and although the FPS goes down and the CPU usage hardly changes, the GPU usage either stays the same or goes down. But, with large changes to a key slider, my GPU usage always goes up until it's eventually pinned at 99%. Like I said before, it's more of an "idiot light" than an exact measure of GPU performance.

But I've also seen what Rob is describing, where you increase a slider a notch and although the FPS goes down and the CPU usage hardly changes, the GPU usage either stays the same or goes down. But, with large changes to a key slider, my GPU usage always goes up until it's eventually pinned at 99%. Like I said before, it's more of an "idiot light" than an exact measure of GPU performance.

Are you using a frame limiter per chance?  If so, that would possibly account for little change when certain sliders are moved.   I run unlimited and this may be a more sensitive way to evaluate GPU Utilization since once the frame limit is hit the GPU doesn't need to amp up work as long as it's on the frame lock.

No, I run unlimited.