Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Low GPU usage with many objects.

Author
Message
Inflictive
17
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 2nd Aug 2013 02:04 Edited at: 2nd Aug 2013 02:09
I have run into a performance-related problem in making my game. I made a small program to isolate the problem:



Running this program at 1080p gives 150 fps and ~20% GPU usage (as reported by GPU meter.) CPU usage is ~%60 on one core, ~%40 on another, and none on the others.

-Using hi-poly spheres instead of cubes increases gpu usage, but not framerate.
-Moving everything close to the camera increases gpu usage, but not framerate (because it has to draw more pixels).
-Not using instancing reduced framerate from 150 to 90, and dropped gpu usage as well.
-Using only one cube has %97 usage and OVER 9000 fps

The GPU meter is not the problem. Almost all other games show %95-%100 usage on it at all times, except for Arma 2, which is known to have a low gpu usage.

The problem is some sort of overhead processing it does on all objects. My game will have a lot of cubes bouncing around, is there some way to optimize this?
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 2nd Aug 2013 02:30
One thing I noticed the other day is that a lot of render states are set in anticipation of drawing each limb of each object. Since these will not change most of the time that is of course highly unnecessary. There likely are more such things that are done per object / limb / polygon to be as extensible as possible, albeit at the cost of effectiveness when values are shared between renders.

Lastly I only get ~120FPS running your code in 1920x1080 with my one month old graphics card... oh, the chagrin!


"Why do programmers get Halloween and Christmas mixed up?"
Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 2nd Aug 2013 07:20
Dark Basic Pro doesn't use multi threading for almost anything. There's a few exceptions where sound and plugins are concerned. So when you SYNC the screen there's probably some efficiency issues you are going to be stuck never able to solve.

With everything else you need to get crafty about skipping as much work for the hardware as possible. You need to really make sure you are doing as little per cycle as you can get away with.

Also keep in mind that dropping from 150 to 90 frames a second is tiny compared to dropping from 50 to 40 frames for example. The higher the frame rate, the shorter each frame is and tiny delays make big swings in frame rate.

This is a classic optimization and efficiency issue. Use Exclude Object On... on all objects outside of view. And make your game code as efficient as possible. This will reduce the overhead.

Inflictive
17
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 3rd Aug 2013 06:26
I did a test once with exclude object on vs not making the object at all, and there was a large performance loss when having excluded objects sitting in memory. Why?

If anyone knows how to compile the dlls for DBP we could fix some problems like this in the source code (it's open source now). Sometime I'll dig into the source code and try and figure out what is causing the lag.
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Aug 2013 15:56 Edited at: 3rd Aug 2013 16:20
I'm not sure I understand what the problem is.

Also, I tried to use GPU Meter but couldn't get meaningful results from it. Which bit of output are you referring to when you say things like "20% GPU usage"? I get 0% with your code using the default builtin graphics and something a bit higher when I force it to use the NVidia GPU (and get a rapidly increasing temperature ).

Here's a screenshot comparing the two



[Edited image to include results using spheres with NVidia GPU and full desktop settings. I'm still not sure what the issue is - spheres seem to be more demanding of the GPU but isn't that obvious? Why would you want the GPU to have high usage? ]
Inflictive
17
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 3rd Aug 2013 20:53
The code is meant to run as fast as possible, just like most pc games. If Gpu usage is not close to 100%, that shows there is some kind of performance bottleneck. In this case it doesen't matter because the framerate is over 60 no matter what, but with more objects (or on a low-end pc) this could mean the difference between 20 fps with low usage and 60 fps with full usage. The Gpu usage is the percent of the Gpu's available clock cycles which are actually used , a low usage means wasted performance.

Also, why would you use the integrated graphics if you have a dedicated Gpu? How do you even choose? I have the intel hd graphics 4000 in my desktop and it's never been used because... it's crap...
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Aug 2013 21:32
Quote: "why would you use the integrated graphics if you have a dedicated Gpu"


Because it seems to be the default - and I haven't noticed much difference when I've changed it.

Quote: "How do you even choose"


Right click on the exe icon, then choose "Run with graphics processor" listed among the various standard options such as "Open", "Run as administrator", etc. I think it's an NVidia Optimus thing or something. I can then choose which processor. Only discovered a couple of days ago I could do that (I've had the thing several months now ).

Quote: "The Gpu usage is the percent of the Gpu's available clock cycles which are actually used , a low usage means wasted performance."


But if you're not doing anything much GFX wise then the CPU stuff becomes a greater proportion of the load - and you need to compare like with like anyway. The games which use 97% are probably GFX bound. Putting a few instanced cubes on the screen isn't exactly a heavy load. When you're getting 9000 fps then the CPU presumably needs to communicate with the GPU 9000 times a second even if the screen itself isn't updated. I take your point nevertheless. I've managed to get a GPU usage of 60% or so with DBPro. Haven't checked commercial games yet though.

Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 3rd Aug 2013 23:01
Nice new avatar and banner set, Green Gandalf; lol

So, what are the performance figures for 5000 limbs in one object? Does that not cut down unnecessary update calls? Afterall, not everything has to be an object; furthermore, not everything has to be a limb.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Aug 2013 23:08
Quote: "Nice new avatar and banner set, Green Gandalf"


Free Banners From MrValentine

Thanks.

Mage
Valued Member
19
Years of Service
User Offline
Joined: 3rd Feb 2007
Location:
Posted: 4th Aug 2013 03:32
I'll agree Exclude Object doesn't solve the problem completely. The Excluded Objects do slow down the programs still.

A good example of where this is a problem is Post Processing. You draw the entire frame and then you want to stick that image on a screen sized surface to render the image with some additional effects. The game world even though you might exclude all of it still slows down rendering that one screen object.

A good reason why post processing in DBP kills frame rate.

Inflictive
17
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 5th Aug 2013 04:31
The problem is that the example program should be pretty much entirely Gpu-bound. After all, all that it does is render cubes. Dark basic is doing some sort of unnecessary cpu overhead when rendering each object; we need a way around this.

I did a test with limbs and noticed that having excluded limbs in memory has extremely little effect on performance, much less than excluded objects.

Rendering 5000 cubes as limbs was also much faster than rendering them as objects.

Hiding objects and using set object mask had the same performance, and using exclude object was faster than either.
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Aug 2013 13:54 Edited at: 5th Aug 2013 13:56
I noticed something in my engine today that might be a related clue. With just one cube in view, and about 10 primitive hidden objects; cubes, plains etc; I am getting just 30 FPS

No shaders or any complex resources; all of my loop algorithms disabled. The only abundance is the amount of arrays and ranges of reserved vectors and resource identities.

I am trying to narrow things down to pin point what the Sync command is up to. I might need to spot what is going on in the DBP source code if I can grasp it; unless someone already knows.

Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 5th Aug 2013 15:00
I believe reserving ID's slows things down.

KISTech
18
Years of Service
User Offline
Joined: 8th Feb 2008
Location: Aloha, Oregon
Posted: 5th Aug 2013 16:43 Edited at: 5th Aug 2013 16:43
I've been away for a while, but from what I remember, DBP does most everything with the CPU and you don't get much GPU usage until you start adding shaders to the mix.
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 5th Aug 2013 16:52 Edited at: 5th Aug 2013 16:53
I was thinking about that, but an ID range test indicates no speed change. Creating say 5000 objects or sprites from say ID 1000000 made no difference; I have not yet seen in the SDK how resource IDs are handled but it seems like there is a dynamic list in there somewhere.

It is all clear that vertex groups are the least intensive, and objects are the most intensive 3D elements here. It is to do with the resource checks and loops.

Loading the attached single limb object with 128 cubes made into vertex groups dropped my FPS from 1000 to 500 FPS; it appeared to take 2 milliseconds for the vertex dense object to render; but this delay has little to do with the density of the object. This is probable because loading 5 of them did not slow things down much. That's 5 * 128 cubes, (7680 polys). Loading 10 of them dropped the framerate to 300 FPS; and that is with seperate objects.

Creating an 128 limbed object performed at 70 FPS.

Creating 128 cube objects performed at 40 FPS.

So using lots of vertex group shapes with shared textures instead of limb shapes can improve the performance. Using an extra object only when necessary, and an extra limb only when necessary.

Using word processing as an analogy, if you load a small document file into Micrsoft Word, you will use up more resources than if you loaded a text file into Notepad; each document could contain identical content, but the Word document has more features.

So it looks like I will need to go low level and use a shader and a group of vertices to represent minor entities. That way the DBP CPU processing load does not increase as more 'GPU Objects' are created.

I've still not figured out why I only get 40 FPS with nothing happening in my engine; and 1000 FPS in a test program with an identical program loop.

I looked at the Sync function in the DBP C++ SDK and all I see is a series of loops containing render calls per camera. The render calls are dynamic so they point to variable function pointers which I cannot pin point.

FastSync is skipping windows message checks, timing and multimedia update calls. Sync is rendering everything and updating everything; but why are 10 simple objects in one app 25 times slower than the same objects in another? What kind of resource could do this to me?

Inflictive
17
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 6th Aug 2013 00:34
So it seems that having things exist in memory slows down your application... this would explain why excluded objects still affect performance... but why?

Also, I noticed a gain in fps + usage when looking away from large numbers of objects, does dbpro automatically exclude objects which are out of the view frustrum? Or does it just hide them? If so, for post processing you could just put your "final render" camera way out of the area and looking away from the scene so the other objects are excluded.
Mobiius
Valued Member
23
Years of Service
User Offline
Joined: 27th Feb 2003
Location: The Cold North
Posted: 6th Aug 2013 01:05
Quote: "this would explain why excluded objects still affect performance... but why?"

They may not be drawn to the screen, but they have to exist somewhere for when they do get drawn.


Quote: "you could just put your "final render" camera way out of the area and looking away from the scene so the other objects are excluded."

Or use set camera mask.

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 6th Aug 2013 16:55
Quote: "Or use set camera mask"


Does that hide or exclude them?

Interesting discussion. Slowdowns with large numbers of entities are sometimes caused by sorting. I wonder if there's some sorting going on - a depth sort or something like that perhaps?



Powered by Free Banners
Chris Tate
DBPro Master
17
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 6th Aug 2013 21:36
Ok I've increased my performance by 10 - 20 FPS. I had to drop use of Sync Callbacks. These where used as part of my internal benchmarking system; which did not record the timing of that aspect of the program; the reason why I could not think of what was slowing things down.
Quote: "

does dbpro automatically exclude objects which are out of the view frustrum?"


It does.

Inflictive
17
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 7th Aug 2013 00:04 Edited at: 7th Aug 2013 00:11
Set camera mask seems to have the same performance as hiding the objects, not excluding them, so excluding all objects before doing the final render would be faster.

Maybe the problem is sorting as gandalf says. I'm pretty sure it only depth sorts if you use the right flag in set object transparency, but maybe it defaults to that flag or something?

I am going to add shadow mapping to my game next which requires another camera to be updated every frame. The shadow camera uses a simple depth shader on objects it renders, so gpu demand is low, but cpu usage will be just as high so it will pretty much cut framerate and usage in half...

Also, particles. If you make every one of thousands of particles its own object, you would run into this problem big-time. There is a particle system which is probably meant to fix this, but how does it work, and can it be applied to regular objects?
Rudolpho
20
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 7th Aug 2013 12:48 Edited at: 7th Aug 2013 12:50
Quote: "Interesting discussion. Slowdowns with large numbers of entities are sometimes caused by sorting. I wonder if there's some sorting going on - a depth sort or something like that perhaps?"

I think the rendering process goes something like this:



That's just my guess from what I remember when going through the SDK source. I might remember wrong and may very well have missed some big part.


"Why do programmers get Halloween and Christmas mixed up?"
mr Handy
18
Years of Service
User Offline
Joined: 7th Sep 2007
Location: out of TGC
Posted: 17th Aug 2013 00:48
It's the weak point of DBP and nothing you can do with it. Only the workaround - attaching all (possible) meshes and using texture atlas on them, to reduce total object number.

"Just because you’re unique, doesn’t mean you’re useful"

Login to post a reply

Server time is: 2026-07-07 01:53:43
Your offset time is: 2026-07-07 01:53:43