What is troubling to me is that when monitoring the GPU, I find that my GPU on average is only utilized 45 to 60%. When monitoring other games, I have found that the GPU is heavily utilized along with Video Memory. So, what is the cause of this?

I'll give my best shot at trying to answer the question...but first, you need to understand what 'user mode' is vs 'system' mode.. you also need to be aware that 'CPU' usage or GPU usage is based on counters... and having 100% CPU utilization is NO WAY to determine a particular component is being stressed out... My background is 100% in the UNIX world, I have a basic understanding of how 'windows' work, but, in essence, its exactly the same thing... the 'queue lenght' or command 'ring' buffers which are the 'buckets' where you 'send' commands are 'finite' if you saturate them, they get overwritten or can stall other components GPU/CPU, so CPU usage is NOT the best way to measure if it is being stressed... you need to take into account what is happening in system mode (at the kernel level) yes.. I know is probably more technical than most would like to hear (and the explanation is overly simplified), but I can't think of another way of explaining it that makes sense.... I you had a linux box and run the top command you'll probably understand what I'm trying to say.. in the UNIX world, the CPU usage is irrelevant... the single most important thing is load average and I/O wait they take into account EVERYTHING thats going on the system. Windows (or in this case) GPU monitoring tools (the ones you are looking at) simply show you how much of the CPU is being used, without taking into consideration factors like I/O or the time it takes for the GPU to fetch the data from the command buffer... so, the numbers you see for GPU usage, are unreliable. No other game (and I mean it) is able to stress the GPU more than FSX, you don't have any idea of the incredibly high number of draw calls that occur per frame in FSX.. its out of this world... Crysys, COD, Mass Effect.. they relay heavily on 'shaders' and GPU's have 'pre programmed instructions' that make the execution ultra fast.. FSX, its spaghetti code.. 15 years old, does it make sense now?

FSX, its spaghetti code.. 15 years old, does it make sense now? YES

FSX, its spaghetti code.. 15 years old, does it make sense now? YES

Not sure if you know this or not but, years ago (15 maybe or more), physical memory was very very expensive. Not too many folks remember but this had an impact on how code was written. To be more detailed, it was necessary to write tight effecient code because there was not much memory available to you. There was a huge emphasis on writing non-fatty code :( So now you know the rest of the story!! Only the guys that wrote code back then know what I am talking about.RegardsBob G

I'll give my best shot at trying to answer the question...but first, you need to understand what 'user mode' is vs 'system' mode.. you also need to be aware that 'CPU' usage or GPU usage is based on counters... and having 100% CPU utilization is NO WAY to determine a particular component is being stressed out... My background is 100% in the UNIX world, I have a basic understanding of how 'windows' work, but, in essence, its exactly the same thing... the 'queue lenght' or command 'ring' buffers which are the 'buckets' where you 'send' commands are 'finite' if you saturate them, they get overwritten or can stall other components GPU/CPU, so CPU usage is NOT the best way to measure if it is being stressed... you need to take into account what is happening in system mode (at the kernel level) yes.. I know is probably more technical than most would like to hear (and the explanation is overly simplified), but I can't think of another way of explaining it that makes sense.... I you had a linux box and run the top command you'll probably understand what I'm trying to say.. in the UNIX world, the CPU usage is irrelevant... the single most important thing is load average and I/O wait they take into account EVERYTHING thats going on the system. Windows (or in this case) GPU monitoring tools (the ones you are looking at) simply show you how much of the CPU is being used, without taking into consideration factors like I/O or the time it takes for the GPU to fetch the data from the command buffer... so, the numbers you see for GPU usage, are unreliable. No other game (and I mean it) is able to stress the GPU more than FSX, you don't have any idea of the incredibly high number of draw calls that occur per frame in FSX.. its out of this world... Crysys, COD, Mass Effect.. they relay heavily on 'shaders' and GPU's have 'pre programmed instructions' that make the execution ultra fast.. FSX, its spaghetti code.. 15 years old, does it make sense now?

Sorry, wrong thread.

I'll give my best shot at trying to answer the question...but first, you need to understand what 'user mode' is vs 'system' mode.. you also need to be aware that 'CPU' usage or GPU usage is based on counters... and having 100% CPU utilization is NO WAY to determine a particular component is being stressed out... My background is 100% in the UNIX world, I have a basic understanding of how 'windows' work, but, in essence, its exactly the same thing... the 'queue lenght' or command 'ring' buffers which are the 'buckets' where you 'send' commands are 'finite' if you saturate them, they get overwritten or can stall other components GPU/CPU, so CPU usage is NOT the best way to measure if it is being stressed... you need to take into account what is happening in system mode (at the kernel level) yes.. I know is probably more technical than most would like to hear (and the explanation is overly simplified), but I can't think of another way of explaining it that makes sense.... I you had a linux box and run the top command you'll probably understand what I'm trying to say.. in the UNIX world, the CPU usage is irrelevant... the single most important thing is load average and I/O wait they take into account EVERYTHING thats going on the system. Windows (or in this case) GPU monitoring tools (the ones you are looking at) simply show you how much of the CPU is being used, without taking into consideration factors like I/O or the time it takes for the GPU to fetch the data from the command buffer... so, the numbers you see for GPU usage, are unreliable. No other game (and I mean it) is able to stress the GPU more than FSX, you don't have any idea of the incredibly high number of draw calls that occur per frame in FSX.. its out of this world... Crysys, COD, Mass Effect.. they relay heavily on 'shaders' and GPU's have 'pre programmed instructions' that make the execution ultra fast.. FSX, its spaghetti code.. 15 years old, does it make sense now?

Yea, that makes sense to me to some degree. I guess if your term "spaghetti code" means "ineffecient and bloated" or just "old" meaning "does not address current hardware effeciently". I guess then it is the orginal code base just modified to some degree. Anway , I hope you can do more testing and have a little more meat to bite into. Right now though it is just testing and that is where I need to say to you "Thanks for your time" RegardsBob

Not sure if you know this or not but, years ago (15 maybe or more), physical memory was very very expensive.

Its much more worse than that ;) there were limitations on the addressing space.. remember himem.sys? but that was more like 20 not 15 years ago :) and DOS comes to mind :)My point is: FSX does a lot of things on the 'CPU' and 'some' got offloaded.. this 'offloading' comes at the expense of 'throwing everything you can to the GPU in a way that was probably experimental for the FSX team.. BufferPools is PROOF of that.. Why would a D3D developer use Explicit Vertex buffers instead of simply batching directly to the API command buffer?If you have programming background, I suggest you take a look at PIX for Windows, its part of the XNA Tools (inside the D3D SDK) you'll need to figure out how to enable the debug bit in FSX.exe :)And no. I WISH I had that tool 3 months ago... I found out everything I posted the HARD old fashion way... the tools simply 'confirm' what I've seen so far and it helps me silence the party poopers (which doesn't have a clue by the way)

Its much more worse than that ;) there were limitations on the addressing space.. remember himem.sys? but that was more like 20 not 15 years ago :) and DOS comes to mind :)My point is: FSX does a lot of things on the 'CPU' and 'some' got offloaded.. this 'offloading' comes at the expense of 'throwing everything you can to the GPU in a way that was probably experimental for the FSX team.. BufferPools is PROOF of that.. Why would a D3D developer use Explicit Vertex buffers instead of simply batching directly to the API command buffer?If you have programming background, I suggest you take a look at PIX for Windows, its part of the XNA Tools (inside the D3D SDK) you'll need to figure out how to enable the debug bit in FSX.exe :)And no. I WISH I had that tool 3 months ago... I found out everything I posted the HARD old fashion way... the tools simply 'confirm' what I've seen so far and it helps me silence the party poopers (which doesn't have a clue by the way)

Yea, no telling why api's were not used, and why they tried to impose there own version of mem management. It may be that they hit a wall and thought they could overcome it. Bob

*******, how can we tell where our bottleneck is if those tools like GPU-Z don't show actual readings of device stress?Any methods / tools you would advise please?I'm running FSX on a Phenom II x4 965 @ 3.4GHz. O.C. didn't help so I just reverted clock speed back to stock. Is it safe to asume then that it's not the CPU that's saturated?My VGA is a ATI radeon 5770. I also tried OC and DC there, to no avail either. Even tested a NVIDIA GTX285 with no impact on performance, but later I found that re-installing FSX made things better so that test might not have been done in valid conditions.Thanks so much for all the effort

Its much more worse than that ;) there were limitations on the addressing space.. remember himem.sys? but that was more like 20 not 15 years ago :) and DOS comes to mind :)My point is: FSX does a lot of things on the 'CPU' and 'some' got offloaded.. this 'offloading' comes at the expense of 'throwing everything you can to the GPU in a way that was probably experimental for the FSX team.. BufferPools is PROOF of that.. Why would a D3D developer use Explicit Vertex buffers instead of simply batching directly to the API command buffer?If you have programming background, I suggest you take a look at PIX for Windows, its part of the XNA Tools (inside the D3D SDK) you'll need to figure out how to enable the debug bit in FSX.exe :)And no. I WISH I had that tool 3 months ago... I found out everything I posted the HARD old fashion way... the tools simply 'confirm' what I've seen so far and it helps me silence the party poopers (which doesn't have a clue by the way)

If you have programming background, I suggest you take a look at PIX for Windows, its part of the XNA Tools (inside the D3D SDK) you'll need to figure out how to enable the debug bit in FSX.exe :)

I once had that PIX installed a few SDKs back and it did seem like a powerful tool but never looked into turning on FSX debug mode to allow it to run in PIX.scott s..

I once had that PIX installed a few SDKs back and it did seem like a powerful tool but never looked into turning on FSX debug mode to allow it to run in PIX.scott s..

Well, we are not 'legally' allowed to 'debug' it :) so... I can't comment more on the issue ;)

@bojote:when using REX 2.0 with 4096 HD-clouds, then FSX.CFG is altered to Texture_Max_Load=4096. I am confused now and asking hereby following:1.) Should I limit my frames via FSX or should I use FPS limiter? And why?

1.) Should I limit my frames via FSX or should I use FPS limiter? And why?

bojote,

None taken :) simply read my latest response (or read Steve original post) everything is there.. EVERY DETAIL!

I see. So it makes sense to ignore Texture_Bandwidth_Multi and just tweak TextureMaxLoad instead, right? Thanks!

It goes like this:If UPPER_FRAMERATE_LIMIT exists, then:MAX_TEXTURE_DATA = (TEXTURE_MAX_LOAD * (TextureMaxLoad * TEXTURE_BANDWIDTH_MULTIPLIER)) / UPPER_FRAMERATE_LIMITIf it doesn't then:MAX_TEXTURE_DATA = TextureMaxLoad * TEXTURE_MAX_LOAD

The bottom line is that they are really all just multipliers. It doesn't matter which one you change since it will change the formula in the same way...Realistically, what matters is that you change the variable that affects your setup...meaning if you have unlimited frames, then don't change TBM. Thanks again for this.

Just wanted to say THANK YOU for this post ! Ihave had the Black Squares problem, particularly in heavy areas, for about as long as I can remember, and have tried everything to fix it. I even posted a topic on this forum a while back without any success. But this (setting TextureMaxLoad=9) has done it at a stroke. I can look out of the window again without cringeing ! Thank You !

Thank you ******* Altuve aka "Bojote" !!!!!!!!!!!!!!!!!!!!!!!!!!!