Very high GPU load 03-16

[Weissrolf]

03-16 creates very high GPU load for no apparent reason when LoS and/or Lighting are enabled, even when no LoS point layers are enabled/present. There are two different observations to me made, though.

1. Maximize image window, no LoS layers present:

New empty image, fullscreen window, LoS + Lighting enabled, locked:
https://i.imgur.com/64EZdzz.png

New empty image, fullscreen window, LoS + Lighting enabled, unlocked:
https://i.imgur.com/auGVegw.png

New empty image, fullscreen window, only Lighting enabled, unlocked:
https://i.imgur.com/c5HidE5.png

New empty image, fullscreen window, only LoS enabled, unlocked:
https://i.imgur.com/jCU8Xzs.png

New empty image, fullscreen window, Los + Lighting disabled, unlocked:
https://i.imgur.com/MRXCjAh.png


New empty image, maximized window, LoS + Lighting enabled, locked:
https://i.imgur.com/JWEZoLK.png


It can happen that the high GPU load of a maximized window gets stuck even after returning to windowed mode.

New empty image, windowed window, LoS + Lighting enabled, locked, stuck after former maximize (even showing load of a fullscreen window):
https://i.imgur.com/Ym51EEL.png

[Weissrolf]

2. Disable vs. Enable LoS layers:

In the Live version GPU load can decrease dramatically by disabling LoS layers, or just LoS points/lines. I posted this as a workaround for high GPU load due to FGU permanently calculating all LoS points of a map even when invisible to tokens (due to many LoS walls in-between). In the 03-16 Beta GPU load stays the same regardless of LoS layers being disabled or even deleted.

Windowed, LoS + Lighting enabled, LoS layers disabled/invisible:
https://i.imgur.com/Zar6qoW.png

Windowed, LoS + Lighting enabled, all layers deleted:
https://i.imgur.com/XH4PyYw.png

PS: As can be seen the deletion of the image layers did not clear the image window and leads to zooming artifacts.

[Weissrolf]

1. FGU Live 4.0.10, Maximize image window, same map as in post 2:

https://i.imgur.com/Q1NUP5J.png

For comparison again, this was an empty map on 4.1 Beta:

https://i.imgur.com/64EZdzz.png

Massive increase in GPU load on the empty Beta map even when compared to a map full of LoS points in Live.

2. Turns out that on this desktop PC using a 2070S switching off single layers' visibility/walls makes no difference either. So I will have to compare 4.1 beta on the laptop with internal Intel GPU.

[Weissrolf]

Any more information needed?

[Weissrolf]

Are there any plans to make token movement not calculate all LoS points on a map, but only the ones that are visible to the token (aka up to the next wall)?

[mapleybacons]

Lighting is a pretty heavy hit to your performance because of how it's calculated. If you're not actively using lighting, try turning it off and seeing how LOS affects your gpu usage.

[Weissrolf]

What post does your reply refer to exactly?

[Weissrolf]

I read your stupid thread, and dismissed your nonsense out of hand, because you are always posting nonsense. You NEVER give full details. Like for example, FULL Windows Version, Full DirectX version, Full Driver versions for all of your hardware. Without those details, your 'benchmarks' mean nothing. You should know that.
Windows 10 Pro 64-bit , 1909, DirectX 12, NVidia driver version 461.72, really "all your hardware" driver versions?


Any more information needed?


Even your Performance nonsense FAILS to provide meaningful insight into what might be happening.
Not sure what to make of this, so feel free to ask for more meaningful information.

[Weissrolf]

Intel 9900K, Nvidia RTX 2070 Super, power-saving disabled, default clock-settings:

Beta 03-31 still suffers from the same issue. This time with the GPU not being down-clocked/under-volted like I usually do for lower noise.

v4.0.10 Live, empty (!) image, full-screen, locked, LoS enabled:
https://i.imgur.com/sjamOte.png

31-01 v4.1 Test, empty (!) image, full-screen, locked, LoS enabled, Lighting disabled:
https://i.imgur.com/CrThrl5.png


31-01 v4.1 Test, empty (!) image, full-screen, locked, LoS enabled, Lighting enabled:
https://i.imgur.com/Ei21nC6.png
https://i.imgur.com/eggq5cs.png

For comparison, WoW Shadowlands, Heart of the Forrest, Hearthstone spawn-point, 180° turn-around, Quality 7:
https://i.imgur.com/SjpX3Lg.png
https://i.imgur.com/S2anGXt.png

[Zarestia]

Just wanted to give data from a different person.

I see the same as weissrolf.
- New campaign in TEST
- New image, empty
- Activate LoS, Lighting, and LoS + Lighting

System: Ryzen 7 3700x, 32 GB DDR4-3200 MHz RAM, RX 5700 XT

All measurements in GPU-Z
Only LoS activated: about 5 - 15% GPU load
Only Lighting activated: about 15-25% GPU load
Both activated: about 35-50 % GPU load

https://i.imgur.com/63NZAAw.png

[Weissrolf]

Again for comparison.

31-01 v4.1 Test, empty (!) image, full-screen, locked, LoS enabled, Lighting enabled:
https://i.imgur.com/Ei21nC6.png
https://i.imgur.com/eggq5cs.png

WoW Shadowlands, Heart of the Forrest, Hearthstone spawn-point, 0° looking towards wall, Quality 10 (maximum!) + CMAA:
https://i.imgur.com/bwRxKE1.png
https://i.imgur.com/PoubCrQ.png

[Weissrolf]

Again: any more information needed?

[Weissrolf]

Another comparison to better judge the proportions of GPU load on my system:

31-01 v4.1 Test, empty (!) image, full-screen, locked, LoS enabled, Lighting enabled:
https://i.imgur.com/Ei21nC6.png
https://i.imgur.com/eggq5cs.png

WoW, Shadowlands, maximum (!) settings + CMAA:
https://i.imgur.com/9Xt1k2K.png
https://i.imgur.com/Xqid2X3.gif

[Egheal]

Quick test on my system :
no FGU GPU 24% CPU 5%
FGU on, start page 24% 8%
FGU campaign on, no image 24% 6%
FGU campaign on, no los, no light 24% 8%
FGU campaign on, los on, no light 29% 6%
FGU campaign on, los on, lights on 35% 8% vsync 0
FGU campaign on, los on, lights on 100% 10% vsync 1
FGU campaign on, los on, lights on 97% 10% vsync 2
FGU campaign on, los on, lights on 96% 10% vsync 3
FGU campaign on, los on, lights on 96% 10% vsync 4

RTX 2070 super, ryzen 9 3900x, 24 different lights on + light on token
So 6% more than los alone and 11% more than no light + no los.
The real dealbreaker here is vsync. I keep it at 0.

[Weissrolf]

VSync 0 is not the same as VSync on/1, though. But great find, because it should give the developers a good clue on where to look for the culprit. Thanks for that! :)

PS: I don't seem to measure a difference between 0 and 1, while 2-4 lower GPU load. Tested with an empty image. Let's see what the next version brings, since several people reported the same problems now.

[Egheal]

Tried "/vsync on" and "/vsync off". Both leads to "Video Sync Rate is 1".

[damned]

/vsync 0 is (iirc) 60fps

[Egheal]

yes, 0 = fixed 60 fps, 1 = match OS frame rate, 2 = half OS frame rate, 3 = third OS frame rate, 4 = quarter OS frame rate. I don't know what is my "OS frame rate" though. Could be interesting to find it. It is probably way higher than 60.

[damned]

your OS frame rate varies
looking at these numbers
it would seem that your OS frame rate is likely a lot higher

[Weissrolf]

You may be using a 144 Hz oder 240 Hz display. Anyway, even at 60 fps the GPU load of FGU is too high for what it does (literally nothing on a blank image).

[Egheal]

What is really weird is that my 2 screens are really basic 2560x1440 at 60Hz. at vsync 0 with a 2001x2027 (5.85 Mo) image, full los and lighting, the load on my GPU is only 11% more than not using FGU, hardly a big deal imho. The fact it is going 100% at vsync 1 and hardly reduce with vsync 2,3 and 4 is very strange though.
Did someone knows if my Vsync choice is transfered to my players ? or need i to tell them to use "/vsync 0"?

[Griogre]

The vsync settings are independant per machine and your players may find a different setting works better than yours depending on their hardware setup.

[Egheal]

ok thanks, i will test with them the best vsync for their machines!

[Weissrolf]

Empty (PF2) campaign (no modules), 1 image (14800 x 10200, no walls), LoS + Lighting enabled, 1 token (22.5 bright, 42.5 dim), windowed image in FGU, FoW enabled in Foundry (demo GM server)

FGU vs. Foundry (Chrome + Edge), 6.25% CPU =~ 1 core maxed out
https://i.imgur.com/8HYSiFm.png

FGU, PC client:
https://i.imgur.com/uN9Mu7T.png

Foundry, PC client:
https://i.imgur.com/dlC9dR2.png

PS: GPU driver power-saving is disabled, aka no down-clocking of the GPU.

[Zarestia]

Hello all,

I've found a 100% sure way to reduce GPU immensely/replicate the GPU load issue.

Ryzen 7 3700x
Radeon RX 5700 XT

Test Campaign (5E), no extensions, empty campaign (got a few images I tested with, can share/upload campaign if you want. This was tested with a 4000px*4000px 2,5 MB JPEG (80% quality). 1 Token with 30' Darkvision. All on the GM machine.

Steps to reproduce:
- Open Assets
- Create image record of the map
- Reset zoom (the other zoom options should work aswell)
- Enable LoS and Lighting
> see about 40-50% GPU Load, even with no token

- Open Assets
- Create image record of the map
- let it be, don't reset the zoom or anyhting!!!
- Enable LoS and Lighting
> see about 5-15% GPU load, even when resizing the map afterwards
--> When you close the map and reopen it, you got again a GPU load of 40-50%

I have found no lighting differences with both methods, but only tested with 1 token.
Maybe this gives a clue to the high GPU load (and resulting performance issues for worse systems).

If you need more information, just ask :)

[Moon Wizard]

@Zarestia,

Thanks for the specific example. I've passed on to @cpinder.

Thanks,
JPG

[Weissrolf]

2. Disable vs. Enable LoS layers:

In the Live version GPU load can decrease dramatically by disabling LoS layers, or just LoS points/lines. I posted this as a workaround for high GPU load due to FGU permanently calculating all LoS points of a map even when invisible to tokens (due to many LoS walls in-between). In the 03-16 Beta GPU load stays the same regardless of LoS layers being disabled or even deleted.

I would like to point to this specific issue again, because it demonstrates a regression from 4.0.10 Live in an area I already deem problematic (calculation of LoS points over the whole map).

[Zarestia]

As all performace threads seem to mix together into a bit of chaos, I will post here again, although this might have some reference to discussion between Moon Wizard and Weissrolf.

I tested some more with my "workaround" from three posts ago.
Same campaign, 12000px * 12000px, 19 MB JPEG (I think 90% quality, not sure), map has a 40*40 grid with 300px/grid (don't know if that matters much). Enabled LoS & Lighting, then resized/resetted the zoom.
Then I went on and added about 300 LoS points (only walls), way less than some other maps, but I was fine with 300. Then added about 15 torches and candles all over the map. Also, 1 PC and 9 NPCs were added. My test NPC was a barbed devil with 120 ft. darkvision.
All testing was done from GM machine with preview of player's view. All movement of Tokens was done without token locking (I saw no difference with locking). The map/image was not put into background, FGU was maximized, vsync is set to default (got a 75Hz FreeSync monitor, don't know if FGU even supports FreeSync... shouldn't matter too much).

Both videos show the map way zoomed out, otherwise you can't really see anyhting. Main difference for about 50% load: LoS edges - see the videos for better demonstration.

The video "workaround_big_image" shows the movement of the NPC over the map, the LoS seems a bit better when you have a 100% zoom, or reset zoom. GPU load: 15%.

The video "big_image_reopened" shows the movement of the NPC after I closed the map and reopened it. You can see way better LoS around the edges, lighting stays the same as far as I can tell. GPU load: 65%.

I haven't found any slowdowns or other issues with both methods, but that is just a few minutes of testing with no player connected. This inital big load on a not too shabby middle-class GPU might lead to some other problems when playing with player's over a long time (what SilenRuin and kevininrussia reported).
I hope this gives a few more clues into all the performance/lag/etc. issues. I sadly didn't have the chance to test with connected players. Feel free to download the attached campaign zip file and test it yourself. Under assets you should find some images with different pixel per grid sizes.

Google Drive Link for Campaign: https://drive.google.com/file/d/1CsRsyH0uuAJ2h1PEy3qhzdXpL8U0iyDh/view?usp=sharing

[Weissrolf]

Great work, thank you! :)

What you are seeing is differences in the "shadows" creation. Game engines usually allow players to set shadow quality, which in turn can affect that stair-case kind of shadow edges. Older games (Battlefield 2 age) used to always have these edges, because GPUs were less powerful back then.

FGU's current "shadow" soft edge creation is problematic in 03-31, because it causes artifacts, both along the edges (aliasing/moire like) and within the dim light areas (single bright pixels). We don't see that in your video, but that might be because the dim area is too far away from the occluders and the video codec might swallow it. You can see it here: https://www.fantasygrounds.com/forums/showthread.php?67493-All-my-TEST-server-campaign-lights-just-went-to-solid-circles-of-light-with-update&p=591551&viewfull=1#post591551

[Zarestia]

I don't see any artifacts in my campaign like in your linked post, but I only moved rather fast to try to get hiccups, which I didn't. The only bothering/problematic things I see with the "reset zoom after LoS/Lighting" workaround is the stair-cases in LoS, which btw seem okayish if you zoom to 100%.
This probably all comes down to how FGU precalculates the LoS and Lighting based on the initial image viewable size (otherwise my workaround would'nt work logically). The rest I and we have to let the devs work out.
If we can get adjustable shadow quality, fog of war and light presets, even for players that of course would be very cool. Imho, that all can come later after the main base system is working well.

I dont have anyhting else to contribute and don't want to spam these threads further with theoretical discussions ;)


I am happy to test and provide feedback again as soon as any updates come out :)

[Laerun]

How big was the map shown below? Did it have a ton of pins, and data points? What are the dimensions or the file size, any idea? I am not familiar with that particular map. As i do not own that content.

[Zarestia]

Laerun, nothing against you personally, as I very much like your work you put into FGC.
But I think your post is not contributing anyhting but more stressful and probably useless discussions. Of course you can't directly compare FGU to WoW. Weissrolf's point was (as far as I understood), that WoW in a still moment has less load than FGU with a blank image (which is true). If that brings anything worthwile for the devs, I don't know. WoW uses a inhouse-engine afaik and not Unreal. The point of Unreal vs. Unity is therefore irrelevant, FGU is on Unity, that won't change. Many great games have been done in Unity, many great games have been done in Unreal, both have different models for payment, no point in discussing these.

We all know Smiteworks isn't Blizzard (I wouldn't even want that), we all know Smiteworks is a rather small company, and we all know that Smiteworks wants to deliver a good product (which most of us want, too).

So let's all slow down for a while and try to give the devs some nice bug/problem/feedback reports with which they can work. Anything else only slows down the real problems.

[Laerun]

I only used Unreal vs Unity as they are both different platforms, Wow uses Unreal. I do agree with you, my comments were not necessary, and I should follow my own example, but it gets to the point where one just wonders "why", and things just really get beyond rationality.. However, I will shut up now, you are right. Apologies to you, the community and WeissRolf. Happy gaming!

[Weissrolf]

New empty CoreRPG campaign, imported your map, maximized the map window to fullscreen and then returned it back to windowed mode:
https://i.imgur.com/T28wtck.png
Looks like your map is too large for FGU to handle.

The "why" is easy: For comparison of GPU load on my system (as in putting things into perspective) I posted examples of how a full 3D world full of lights, particles and moving objects draws less GPU power than FGU displaying a blank image with nothing else going on. It is a showcase of how my powerful hardware is object to strong stress from running FGU doing literally nothing, while a big Lua based game uses less power to deliver a lot more stressing content. It's also a showcase of how strong my hardware is to begin with and still FGU runs into serious problems. It's not the map, it's not the hardware, it's the software.

This is a TEST build (more Alpha than Beta), we understand this. But it won't get anywhere if developers don't take up on this kind of feedback while blaming users' images being too large. Frankly, FGU's current state of performance is ridiculously bad and shifting the blame towards the users is dishonest and aggravating.

[Moon Wizard]

Again, this last post does nothing to help the discussion, but simply attacks our position for saying that we can't handle images that large right now. We know that, and we are looking at. Restating the same argument over and over in different threads just forces me to take away time from working on code to clarify things that are muddied by these kinds of posts.

Regards,
JPG

[Weissrolf]

I did not understand that your position was that you "cannot handle images that large right now" rather than "you are not supposed to use large images". Even less so that you are looking at improving on that.

That being said: The very first post demonstrated that even new empty images cause considerable performance issues. Any answer other than "this should not happen" is the wrong answer, empty image and all. :confused:

Suggestion: Create a "Known issues" thread that makes clear what feedback you copied, what information you are still looking for and what information people don't have to keep repeating.

[Zarestia]

I did not understand that your position was that you "cannot handle images that large right now" rather than "you should not use large images". Even less so that you are looking at improving on that.

That being said: This thread originally was not about large images at all, so why would you keep bringing it up? The very first post demonstrated that even new empty images cause considerable performance issues. Any answer other than "this should not happen" is the wrong answer, empty image and all. :confused:

Suggestion: Create a "Known issues" thread that makes clear what feedback you copied, what information you are still looking for and what information people don't have to keep repeating.

And I already showed a workaround for your/the issue, which was forwarded to cpinder. I don't know why we are all discussing this even further... I suspect the devs read every post in the Support and Laboratory forums, so 1 post with relevant information should be enough, no need to hammer down the same issue tenfold. This thread is btw also a copy from another thread with the same topic... Let them work on an update and test the next update(s) instead of getting into a repetition loop, for real now.

Known issues of course would be nice in the future, can't decline that.

[Neovirtus]

In my opinion, there should be VERY little "discussion" in any of the Support forums (i.e. The Laboratory and Houses of Healing). If you find a bug, or an issue, you post it in a new thread, or an existing thread if you reasonably believe they are the SAME issue. Not a related issue or similar issue. Post the details of your issue, your system configuration, your campaign configuration, and if possible a means of reproducing the issue.

I wish the mods would enforce it this way, as it would clean out the noise and allow the developers to see REAL bug reports without having to sift through opinions and random musings on the state of the software. As much as I appreciate (and share) the passion of many users for improving and optimizing FG, I don't see it as constructive here. I hope the mod team will clarify the rules for posting in the support forums and begin to moderate them, this post included.

[Jiminimonka]

In my opinion, there should be VERY little "discussion" in any of the Support forums (i.e. The Laboratory and Houses of Healing). If you find a bug, or an issue, you post it in a new thread, or an existing thread if you reasonably believe they are the SAME issue. Not a related issue or similar issue. Post the details of your issue, your system configuration, your campaign configuration, and if possible a means of reproducing the issue.

I wish the mods would enforce it this way, as it would clean out the noise and allow the developers to see REAL bug reports without having to sift through opinions and random musings on the state of the software. As much as I appreciate (and share) the passion of many users for improving and optimizing FG, I don't see it as constructive here. I hope the mod team will clarify the rules for posting in the support forums and begin to moderate them, this post included.

Yeah, spot on.

[Jiminimonka]

And I already showed a workaround for your/the issue, which was forwarded to cpinder. I don't know why we are all discussing this even further... I suspect the devs read every post in the Support and Laboratory forums, so 1 post with relevant information should be enough, no need to hammer down the same issue tenfold. This thread is btw also a copy from another thread with the same topic... Let them work on an update and test the next update(s) instead of getting into a repetition loop, for real now.

Known issues of course would be nice in the future, can't decline that.

I agree.

Also, and beside the point, if anyone thinks that the professional software team at Smiteworks, who code 5-7 days a week, is unaware of issues with their software, then that person is unaware of how software development works.

[Weissrolf]

If developers are aware of issues then no need to report anything I guess?! I do wonder then who of the three people does all the QA and why there even is a laboratory forum then? Easy to be judgemental, aye?

A place to discuss and report...

[Jiminimonka]

If developers are aware of issues then no need to report anything I guess?! I do wonder then who of the three people does all the QA and why there even is a laboratory forum then? Easy to be judgemental, aye?

.......

[Trenloe]

There is a *big* difference between reporting/discussing issues, and large amounts of repetitive SPAM across multiple threads, with statements bordering on outrageous claims about how FG operates and how the developers work. It seems like the less people respond, the more desire there is from certain members of these forums to just keep posting and posting the same stuff again and again, and then escalate the discussion with baseless claims. Yes, I know this is the Internet, but the vast majority of us don't want the FG forums to devolve into a click-bait fest of "look at my posts, this is the top issue that everyone should be aware of and should be fixed right now!" ... (time passes) ... "What? Hasn't this been fixed? Hasn't my pontification been recognized as sage advice and everything dropped and acted upon immediately?" ... (posts same generalization data again) ... (and again) ... (and again) ...

The rule here is Quality not Quantity! Some of the data can be useful, and some posts have merit. But they soon get overwhelmed by the repetitive "read my posts and respond the exact way I want you to or I'll keep posting" behavior. One or two posts are fine, then *PLEASE* leave it at that and don't cross post, and don't escalate the discussion with unfounded claims.

We aren't saying that you shouldn't report and discuss issues and topics at hand. What we're trying to get across is that there's an efficient and polite/friendly way to this, and as part of that please don't make inaccurate assumptions (accusations) on FG coding/business practices that you really have little/no knowledge about. These forums pride themselves as a place of friendly refuge from the general Internet at large and the moderators usually don't need to do much to keep this environment intact; except in rare cases.

As I close yet another one of Weissrolf's thread (sigh, will it never end?) I draw everyone's attention to the following post earlier in this thread:


Restating the same argument over and over in different threads just forces me to take away time from working on code to clarify things that are muddied by these kinds of posts.

[Trenloe]

So, I've had a complaint from the OP that I closed this thread that they were specifically asked to create by Moon Wizard. Yes, Weissrolf, you were asked to open this thread - but that person who asked you to create it has posted in this very thread that you're stating "the same argument over and over" and you're also posting misinformation and making accusations. Your complaint shows, in my opinion, that you've lost touch with what Moon Wizard requested, you don't understand how to present issues in a helpful and efficient manner on these forums, and you struggle to take onboard feedback given to you. Things aren't static - they change, and you need to listen to feedback given to you. Maybe you're inability to listen is why you keep posting the same things again and again?

If Moon Wizard has an issue with me closing this thread, then he can easily re-open it. Otherwise, it has more than ran its course and is (as usual with a lot of your threads) beginning to devolve - which is why I closed it. Keep on point. Don't post again and again about the same issue. Don't make wild assumptions. Provide the information requested - ONCE! And your threads won't get closed. I very much doubt you'll read this with an open mind and take it onboard. However, I'm an optimist; I'm hoping that the stars align and a miracle happens...