Using CPU and GPU at the same time

Author

Message

Inflictive

15

Years of Service

User Offline

Joined: 16th Jun 2009

Location: Altis

Posted: 15th Jul 2011 05:32

Link

Hi, i've been working on the 3d main menu for my game. I have been using "Decoupling the game loop from the display loop" at http://forum.thegamecreators.com/?m=forum_view&t=175348&b=6.

With this neat code, I can essentially set the sync rate seperate from the rest of the game so the actual game doesen't always run at different speeds on differently powerful computers. I have the "game loop" set to run at 120-125 Hz, and I have been playing with the display loop, which basically just contains "sync"(although there is a lot existing in the 3d world), while the game loop currently just has a few simple math commands(to keep the 3d stuff moving at the right pace).

When I set the display loop to ~60 hz everything runs fine, and I get about 10% cpu use.

When I set the display loop to 75 or 90 hz, same thing

However, I tried setting the display loop to 120-125 hz, and essentailly everything dropped to 105 hz, with no extra loops(meaning the "lps" variable in the code linked above). I thought I was running my computer to the max, but I still had only 10% cpu use. I played around with dark basic for a while, I had the thought that maybe the GPU was slowing everything else down.

Then I tried forcing antialiasing through the Nvidia control panel, which would decrease performance, and it did. In my game's 3d main menu with both the display and game loops set to ~120 hz, instead of dropping to 105hz like before, it now dropped to ~60 hz, although cpu use was still around 10%.

So, is there a way to make the program use the cpu and gpu at the same time? If I could do that, I could get 120-125 hz in the game loop regardless of computer, and only the frame rate would vary(I think). Or, perhaps use the cpu as a gpu to help the main gpu, instead of just letting the cpu sit idle?

If you need me to post my code, ok, but it will be hard to figure out...

I like Wings 3D and GIMP. YAY.

Back to top

Profile PM

TheComet

17

Years of Service

User Offline

Joined: 18th Oct 2007

Location: I`m under ur bridge eating ur goatz.

Posted: 15th Jul 2011 14:39

Link

You don't need 125 Hz in your game loop, or in your display loop. All games run either at 30 Hz (Conker's Bad Fur Day), 50 Hz (Mario Kart 64), or 60 Hz (pretty much all other games).

What you need to do is make your game loop run at 60 Hz, and the display loop run at 60 Hz. The code in the link makes sure that the game loop keeps running at 60 Hz, even when the display loop can't keep up.

Forget 120 Hz, why would you need to run a game that fast anyway? Our eyes are fine with a refresh rate of 24 Hz, and our persistence of vision is at ~50 Hz. Anything above 60 Hz is a waste of processing power.

TheComet

Back to top

Profile PM Email Website

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 15th Jul 2011 20:19

Link

Pretty much what TheComet said, but I think you're missing the point of the Decoupling code.

It's meant to allow you to pick a Display Loop frequency that will become your desired FPS. (typically 30, 50 or 60) Then as your game complexity increases the Game Loop speed should decrease, leaving your Display loop enough power to maintain the desired rate.

If your monitor is running at 60-75Hz, which is typical, then syncing at anything above that frequency is just wasted performance.

Back to top

Profile PM Email Website

Inflictive

15

Years of Service

User Offline

Joined: 16th Jun 2009

Location: Altis

Posted: 15th Jul 2011 21:27

Link

Quote: "It's meant to allow you to pick a Display Loop frequency that will become your desired FPS. (typically 30, 50 or 60) Then as your game complexity increases the Game Loop speed should decrease, leaving your Display loop enough power to maintain the desired rate."

Wait, why would you want the game loop speed to decrease? If the game loop speed decreases, the pace of the game would slow down with it. Wouldn't it be better for the fps to drop as long as the game keeps running at the same speed?

May the source be with you.

Back to top

Profile PM

Neuro Fuzzy

17

Years of Service

User Offline

Joined: 11th Jun 2007

Location:

Posted: 15th Jul 2011 21:58

Link

How many cores do you have? If you have one of those fancy quad core hyperthreaded ones with 8 virtual cores, then the maximum usage DBPro could get would be 100% of 1 core (I think), which would be 1/8th or 12.5% cpu usage.

If not... all I can think of is: code?

Why does blue text appear every time you are near?

Back to top

Profile PM Email

Quel

15

Years of Service

User Offline

Joined: 13th Mar 2009

Location:

Posted: 15th Jul 2011 21:59

Link

Game loop is the place where you do calculations.
Display loop is the place of visible action.

The first CAN and WILL decrease as long as it still can do the job. If it decreases more, the display loop will suffer from it.

-In.Dev.X: A unique heavy story based shoot'em ~35%
-CoreFleet: An underground commander unit based RTS ~15%
-TailsVSEggman: An Sonic themed RTS under development for idea presentation to Sega ~15%

Back to top

Profile PM

TheComet

17

Years of Service

User Offline

Joined: 18th Oct 2007

Location: I`m under ur bridge eating ur goatz.

Posted: 16th Jul 2011 01:07

Link

Quote: "It's meant to allow you to pick a Display Loop frequency that will become your desired FPS. (typically 30, 50 or 60) Then as your game complexity increases the Game Loop speed should decrease, leaving your Display loop enough power to maintain the desired rate."

You sure about that? I thought the game loop has to be running at a constant 60 Hz (so the game can't run any faster or slower), and the display loop may vary according to what is being displayed. That's the whole point of decoupling the display loop from the game loop.

TheComet

Back to top

Profile PM Email Website

Inflictive

15

Years of Service

User Offline

Joined: 16th Jun 2009

Location: Altis

Posted: 16th Jul 2011 01:27

Link

Quote: "How many cores do you have? If you have one of those fancy quad core hyperthreaded ones with 8 virtual cores, then the maximum usage DBPro could get would be 100% of 1 core (I think), which would be 1/8th or 12.5% cpu usage."

I was watching the cpu use when running my game, and one time my processor use jumped to like 70% on my dual core, so I don't think so... but then again that was when playing the WMV intro, so it may still be limited in 3d. It shouldn't be though...

Quote: "Game loop is the place where you do calculations.
Display loop is the place of visible action."

Wait... I thought the purpose of KIStech's code was to make games always run at the same pace, so if I set my game loop to 60hz and use these sort of commands in it:

move + update objects
update inputs n' things
phy update
ai update

etc.
And let the display loop run at whatever pace, with these commands:

point billboard objects toward camera
sync

If the game loop is not stuck at 60hz, then a user with a slow computer would experience the game differently, besides just a lower frame rate. I'd rather have the framerate drop then have the game appear to move in slow motion.

The way I see it, the game loop should ALWAYS stay at 60hz, and the display loop(basically just SYNC) should eat up whatever power is left over(unless Vsync is on, in that case the display loop would be capped at 60/65/75/85/whatever monitor's framerate is)

Based on my knowledge, the GPU does "sync" and the CPU does everything else, so why not run both simultaneously?

May the source be with you.

Back to top

Profile PM

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 16th Jul 2011 19:13 Edited at: 16th Jul 2011 19:14

Link

Quote: "Wait, why would you want the game loop speed to decrease? If the game loop speed decreases, the pace of the game would slow down with it. Wouldn't it be better for the fps to drop as long as the game keeps running at the same speed?"

I see the confusion now.

Timer Based Movement fixes all of that. Your game loop should run as fast as it can, using Timer Based Movement to move everything. The only job the Display loop has is to take a snapshot of that activity at your desired framerate.

So no matter how slow or fast the computer is, within reason of course, the Game Loop is supposed to adjust it's speed to compensate using Timer Based Movement to put things where they belong in that moment in time, which allows the Display loop to remain steady.

Back to top

Profile PM Email Website

Inflictive

15

Years of Service

User Offline

Joined: 16th Jun 2009

Location: Altis

Posted: 16th Jul 2011 22:29

Link

Hmm, I think I see what you are saying. For example, to move the player's ship, would I put somethig like this in my "game" loop?:

Move object 1,(10/GPS)

That way it should move at 10 units per second. However, why would you want that? If the game loop speed is more than 60hz, objects wouldn't update on the screen any more often than 60fps anyway. And it seems to me that SYNC takes up most of the power, so say the user has a weak computer:

With a dynamic game loop speed and a static 60fps screen, the game loop might only update at 15hz. The game seem to would run at the same speed, but would also seem to have a low framerate (15 fps). This is because the computer essentially has to draw the same thing 4 times.

However with a static game loop speed at 60hz, and a dynamic framerate, the user could get more like 30 fps because the computer doesen't waste power drawing the same thing multiple times. Given, it does waste a little power running the game loop more than it needs to, but not much.

You idea of timer based movement got me thinking. Why not use a loop code like this:

X as integer
Y as integer
Oldtimer as double integer
Do
If oldtimer>=timer()
Oldtimer=timer()
y=x
X=0
Endif

Move object 1,(10/y)
Other game stuff...

Sync rate 0
Sync
Inc x
Loop

With this arrangement, y is the loops per second, x is a variable, and oldtimer finds out when a second has
passed. The game and display loop are one. This way, there would be no wasted computer power. The game could run at any fps, so any monitor at max fps if the computer is powerful enough. A slow computer would have a low fps, but there wouldn't be any wasted power. Timer based movement is incorperated so the game runs at the right speed. What do you think?

May the source be with you.

Back to top

Profile PM

=PRoF=

21

Years of Service

User Offline

Joined: 17th Mar 2003

Location: Milton Keynes, UK

Posted: 16th Jul 2011 23:02 Edited at: 16th Jul 2011 23:04

Link

You really need to be using Timer based movement in conjunction with the decoupling code.

The theory behind TBM is that You specify a speed per second for an object etc, and then you multiply that by whatever fraction of a second your game loop took; thus making everything appear to move at the same speed regardless of PC spec.

There is an abundance of helpful information on Timer based movement on these forums, just have a search (And maybe read thru the decouple the display loop forum thread, coz I'm sure TBM is a big part of it)

Hope that helps.

>Edit<
Always remember to refresh the page before replying! d'oh. sorry for repeating stuff.

Bitmap Font Creator Alpha Out Now!

Back to top

Profile PM Email Website

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 16th Jul 2011 23:14

Link

Quote: "The game and display loop are one. This way, there would be no wasted computer power. The game could run at any fps, so any monitor at max fps if the computer is powerful enough. A slow computer would have a low fps, but there wouldn't be any wasted power. Timer based movement is incorperated so the game runs at the right speed. What do you think?"

That's not the point of Decoupling though. In a perfect world you don't want your FPS to change at all. The fact that the Game loop changes speed is what will adjust for slower or faster computers.

When you use proper Timer Based Movement the speed of the Game loop doesn't matter, as long as it isn't lower than the Display loop speed.

Read up on Timer Based Movement like Prof mentioned. It will help a lot. Then go back through the Decoupling thread. It will become clearer.

Back to top

Profile PM Email Website

Inflictive

15

Years of Service

User Offline

Joined: 16th Jun 2009

Location: Altis

Posted: 19th Jul 2011 03:06

Link

Ok, I think I understand the decoupling code now. In the third example(from the decoupling thread) you set the fps to 30 and the game loop to 120hz. I assume the game loop was at 120hz to increase the precision of things like collision detection(if it was a real game). If the computer was too slow, I think the game loop would slow down a LOT. Even though objects on the screen would seem to move at the same rate(due to TBM), things like collision detection may not work. In my opinion, it would be better if the fps dropped a little bit.

Or, like TheComet said, you don't even need a 120hz game loop. So if you set both loops to 60hz, they would drop at the same rate on a slow computer. But if you do that, you don't even need the decoupling code... just do something like example 2 in the decoupling thread.

Quote: "On a fast computer you can get quite high framerates with that, but again, it eats up all the available CPU cycles.
"

Yes, but then set Vsync on or put a NICE WAIT in it.

This method has the added bonus of catering to the 600hz plasma monitor-quad core intel i7 type people, and with timer based movement, the game should still run at the same speed. Also, you could get even more performance out of it with multithreading, since the GPU does sync and the CPU does everything else.

One problem I found while messing with the decoupling code, if I set the display loop speed to 60, which is my monitor's actual speed, I noticed strange "pauses" in the movement of objects on-screen. The object's movement paused for about 400ms every few seconds, and setting the display loop speed to about 90 fixed this. The game loop speed was set at 125hz the whole time.

May the source be with you.

Back to top

Profile PM

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 19th Jul 2011 08:36

Link

There may be something else causing the slowdown. Hard to tell.

The TBM used in the Decoupling example is very basic. If you add smoothing to it, then that pause would be less noticeable. The downside of smoothing is you lose a tiny bit of accuracy.

If you've seen the TBM thread where Mage and I had a disagreement about a few things, then you've seen the smoothing code. Without it there are times that the loops run fast enough that the factor# returns. 0.0, in which case nothing moves. The smoothing averages the factors across 30 loops.

Collision detection should be unaffected by Decoupling, since you're doing that in the Game loop, which if it's running faster should give you very speedy collision detection.

The sole purpose of the Decoupling code is to maintain a steady framerate and allow the Game loop speed to fluctuate as needed. Whether the Game loop runs at the same speed as the Display loop, or 20,000 loops per second doesn't matter. TBM takes care of the movement, and collision detection should work just like it always does because it doesn't rely on a sync() to set things where they're supposed to be.

Having said that, you would have to be careful using Decoupling with physics, such as Sparky's. You have to Update the object in the GAME loop for it to work properly.

The Display Loop's only purpose is to prepare any 2D images that should be on screen, print any needed text, and do a sync to put everything on screen.

Back to top

Profile PM Email Website

Inflictive

15

Years of Service

User Offline

Joined: 16th Jun 2009

Location: Altis

Posted: 19th Jul 2011 22:16

Link

The "pauses" I was talking about actually occured when I wasn't using TBM. Don't know what causes that, but I do know what fixes it, having an unnecessarily high framerate. Using the "smoothing" might help, but I don't think anyone will notice anyway.

What I mean about collision detection is, say 2 objects are moving at eachother at 60 units per second. The objects are spheres, with radius 0.1 units. If the game loop rate was 600hz, the objects would step 0.1 units at a time and would certainly hit each other at some point. However if the game loop rate is 60hz, the objects would step 1 unit at a time, and probably "skip over" each other. True, a sphere with radius 0.1 units going 60 units/second would be very fast, but still...

You say if the computer is having trouble, the game loop should slow down to allow the fps to stay the same. In the decoupling thread, you said:

Quote: "Using this method on the server app for Worlds Apart Online, it runs the Game Loop at around 23,000 loops per second with a Display Loop rate of 5 FPS. Perfect for a server that needs to handle lots of network traffic but doesn't need much of a display.

The client for Worlds Apart Online is able to maintain 40 FPS with a Game Loop rate of 80-90 loops per second"

This makes it sound as if the game loop takes up VERY VERY LITTLE power compared to the display loop. Since it sounds as if you could "trade" 22900 game loops for only 35 display loops. So, even if the computer was only strugging a little, I think the game loop would drop from 120hz to 60hz (the display loop rate) very quickly.

If I wrote my game similar to example 2 in the decoupling thread, the only problem I can think of is dark physics, which needs to run at a steady rate. It shouldn't be too hard to make it work though, using some timers and equasions and things...

<img>http://inflictivestudios.ueuo.com/banner.bmp</img>

Back to top

Profile PM

Dar13

16

Years of Service

User Offline

Joined: 12th May 2008

Location: Microsoft VisualStudio 2010 Professional

Posted: 20th Jul 2011 06:39 Edited at: 20th Jul 2011 06:42

Link

Quote: "This makes it sound as if the game loop takes up VERY VERY LITTLE power compared to the display loop."

If it doesn't run at least twice as fast you have a bottleneck or two in your game loop code. Or a poorly optimized section of code is running extremely slow.

Back to top

Profile PM Email

TheComet

17

Years of Service

User Offline

Joined: 18th Oct 2007

Location: I`m under ur bridge eating ur goatz.

Posted: 20th Jul 2011 10:17

Link

Quote: "This makes it sound as if the game loop takes up VERY VERY LITTLE power compared to the display loop."

That's because it does. The GPU has to do a lot of processing, think of all of the calculations it takes to just display a sphere. That's why GPUs have more than 200 cores in them, so everything can be processed in parallel. Even if the GPU could run faster, there is absolutely no need, because your monitor can only manage 60 Hz. End of Story.

All the CPU does in a game is coordinate everything. It's not a lot it has to do, here is the list:

-mouse input
-keyboard input
-variable control
-send certain updates to the GPU

That's all it's designed for. If you try and render a scene from a game using only the CPU, it would take ages. Have you ever rendered a scene in blender? It can take up to 20 minutes in my expirience, where the GPU could handle that in 10 ms. So asking if you could process some of the graphics on the CPU is absurd. It's like asking a cook to design and program a gaming console.

TheComet

Back to top

Profile PM Email Website

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 20th Jul 2011 20:08

Link

For collision detection, if done right, things should never skip over each other. You always do your raycast/spherecast from the object's current position to it's new position, which should detect everything in between.

For my server, the unusually high Game Loop rate is when there are no players online. As players join, certain parts of the Game Loop code become active, and the Game Loop will slow down a little with the addition of each player. The Display loop will remain at 5 FPS no matter what.

With this scenario, a DBPro server could theoretically handle several hundred players at once.

Back to top

Profile PM Email Website

Sorry your browser is not supported!

Newcomers DBPro Corner / Using CPU and GPU at the same time