Jump to content

  • Log In with Google      Sign In   
  • Create Account


Stutter / Micro Stutter Even w/ VSync


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
35 replies to this topic

#21 mark ds   Members   -  Reputation: 1132

Like
1Likes
Like

Posted 08 November 2013 - 09:37 AM

I remember something like this from many years ago.

 

Do you notice the stutter if you look away from the screen and use your peripheral vision? I seem to recall that some people are more sensitive to it than others, and that it tended to disappear as scene complexity grew.

 

Also, are you sure your monitor is at 60hz? Many run at 59 *or* 60 (my Dell can be set to 29, 30, 59 or 60) - perhaps there is a hardware mismatch somewhere.



Sponsor:

#22 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 08 November 2013 - 10:31 AM

I ran your sample (on Windows) and I don't see any stuttering, though the timings in the console log varies a lot, some are 1ms and some are 15 etc, but the actual animation seems smooth.

Not that I would be likely to notice anything wrong as the image moves so slowly and quickly goes off screen.

 

Window mode usually doesn't have perfect vsync, and often can't have perfect vsync (as it shares the sync with other apps). You have to go to exclusive fullscreen.

 

I have no idea how Linux drivers work, but as long as other games work correctly and you swap in fullscreen mode with time to spare until vsync I don't see why you would get stuttering.

 

Erik, thank you very much for running it on your system. I really appreciate the help.

 

I am definitely running in windowed mode, and I noticed when I went to fullscreen in Windows the problem almost completely disappears. In windowed mode though, the stutter can still be seen and this problem does not occur with other games. Your explanation of not being able to have perfect VSync makes sense though, thank you.

As for Linux though, it still does not explain why the stutter is so prevalent - and this is with glut or with SDL. It's like it takes the Windows problem and enhances it. And I have the latest drivers on 12.04 and on 13.04, but for 13.10 it is just rolled into the OS. I wonder if this happens on CentOS or another distro....

 

Still doesn't make sense to me why other games don't have the same problem, such as the Gish game. Same environment, with no apps running, etc.


Edited by martinis_shaken, 08 November 2013 - 10:39 AM.


#23 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 08 November 2013 - 10:36 AM

I remember something like this from many years ago.

 

Do you notice the stutter if you look away from the screen and use your peripheral vision? I seem to recall that some people are more sensitive to it than others, and that it tended to disappear as scene complexity grew.

 

Also, are you sure your monitor is at 60hz? Many run at 59 *or* 60 (my Dell can be set to 29, 30, 59 or 60) - perhaps there is a hardware mismatch somewhere.

 

Yep, definitely happens if I look away and use peripheral. Didn't know that could happen though, that's cool. I will check now to ensure that the monitor is in fact at 60hz, but if it isn't then VSync should be able to figure that out I would hope. There is something with frames being dropped though, some way some how.

 

Edit:

 

god@god-laptop:~$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 32767 x 32767
LVDS1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1366x768       60.0*+   40.0  
   1360x768       59.8     60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
 
 
Yes it does run at 60fps, and when I try setting it to 40 it all flickers like crazy.

Edited by martinis_shaken, 08 November 2013 - 10:47 AM.


#24 Kaptein   Prime Members   -  Reputation: 1954

Like
0Likes
Like

Posted 09 November 2013 - 08:33 AM

I had stuttering issues myself, but it only happened on windowed linux and windowed AND fullscreen windows

My imperfect solution was to interpolate player camera rotation and movement (separately)

I didn't interpolate movement or rotation before, so when i did with rotation it became really smooth.

After that I just added weight to player position (very stupid 'fix',) but it actually works ok

 

like

player.xyz = oldPlayer.xyz * weight  +  newPlayer.xyz * (1.0 - weight);

 

where old and new are only updated each time the physics thread is updated

I'ts not a solution, but if it makes things smooth for you, like it did for me, at least we both know the reason smile.png

the physics thread just didn't update regularly enough because of the variable amount of background work it does and the irregularities in the update frequency

 

Also, for rotation i just interpolated pitch/yaw/roll, because that made things simpler (no need for slerp)


Edited by Kaptein, 09 November 2013 - 08:35 AM.


#25 Hodgman   Moderators   -  Reputation: 28591

Like
0Likes
Like

Posted 09 November 2013 - 08:35 AM

Do you have a virus scanner active?



#26 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 09 November 2013 - 09:06 AM

I had stuttering issues myself, but it only happened on windowed linux and windowed AND fullscreen windows

My imperfect solution was to interpolate player camera rotation and movement (separately)

I didn't interpolate movement or rotation before, so when i did with rotation it became really smooth.

After that I just added weight to player position (very stupid 'fix',) but it actually works ok

 

like

player.xyz = oldPlayer.xyz * weight  +  newPlayer.xyz * (1.0 - weight);

 

where old and new are only updated each time the physics thread is updated

I'ts not a solution, but if it makes things smooth for you, like it did for me, at least we both know the reason smile.png

the physics thread just didn't update regularly enough because of the variable amount of background work it does and the irregularities in the update frequency

 

Also, for rotation i just interpolated pitch/yaw/roll, because that made things simpler (no need for slerp)

I'm not sure I understand this one completely, but the way I interpret it is having the player's movement depend on the delta between frames? If that is so, then it does do that already. Same for the scrolling of the background and everything else. The whole environment runs off a delta (which made me think of taking that out and seeing what happens when it doesn't - which is why I made the sample program I put on Github to take out all the variables I could).

 

 

Do you have a virus scanner active?

 

No sir, I do not. In fact I killed all running processes that were not critical in both Windows and Linux - and even reformatted Linux (and also upgraded it to Ubuntu 13.10 and installed only the SDL2 libs), AND reinstalled my video drivers in both Linux and Windows.



#27 tonemgub   Members   -  Reputation: 759

Like
0Likes
Like

Posted 11 November 2013 - 01:32 AM

Not sure why I didn't think of this before, but is it possible that your stuttering is caused by the fact that you're writing to the console window every frame? I just tested the sample code on Windows... The regular size for the console window buffer is 80x300 characters, and with that setting, I get no/low stuttering. When I changed the buffer size to 3000x3000, it started stuttering the way you describe, and it was worse when I maximized the console window. The Linux console window probably also has this issue.

 

Another way I can think of to reproduce this would be to pipe the output of your program's stdout to a file.

 

IF you comment out the code that prints to the console, do you still get the stuttering?



#28 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 28 November 2013 - 09:28 AM

Not sure why I didn't think of this before, but is it possible that your stuttering is caused by the fact that you're writing to the console window every frame? I just tested the sample code on Windows... The regular size for the console window buffer is 80x300 characters, and with that setting, I get no/low stuttering. When I changed the buffer size to 3000x3000, it started stuttering the way you describe, and it was worse when I maximized the console window. The Linux console window probably also has this issue.

 

Another way I can think of to reproduce this would be to pipe the output of your program's stdout to a file.

 

IF you comment out the code that prints to the console, do you still get the stuttering?

 

Sorry for the very delayed response - been out of the country the past couple weeks. I did try removing all the output statements, piping them to a file, limiting them, etc. and the problem still persists.



#29 tonemgub   Members   -  Reputation: 759

Like
0Likes
Like

Posted 28 November 2013 - 12:16 PM

I'm out of ideas, sorry.



#30 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 28 November 2013 - 05:04 PM

I'm out of ideas, sorry.

 

 

Haha, it's okay. I am too, and I'm baffled. If I ever figure it out I'll be sure to post. Thank you very much for the help though everybody!!! :)



#31 DvDmanDT   Members   -  Reputation: 834

Like
0Likes
Like

Posted 28 November 2013 - 05:13 PM

Some quick questions..

 

For how long does a frame stay when it stutters? Are we talking 2-3 frames or more?

 

Can you give some more detailed specs on your test systems?

 

Windows (and most likely Linux) parks unused CPUs and unparks them when needed. This is supposed to be transparent, but it's not. Maybe other games just use more cpu and therefore keep them unparked while you end up just on the line causing it to toggle them all the time?

 

What energy setting are you using? In Windows, make sure you are using High Performance or vendor-specific equivalent.



#32 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 29 November 2013 - 09:03 AM

Hello, and thanks for participating!

 

I would say 2-3 frames, if I had to guess. You should be able to replicate it via the sample program I posted on github 

https://github.com/martinisshaken/Sample-SDL2-OpenGL-Program

 

As for system specs, this is the info for my laptop:

 

/proc/cpuinfo:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel® Core™ i3-2310M CPU @ 2.10GHz
stepping : 7
microcode : 0x1a
cpu MHz : 2093.189
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
 
/proc/meminfo:
MemTotal:        6099052 kB
MemFree:         3653744 kB
Buffers:          119444 kB
Cached:          1361440 kB
 
NOTE: I run ubuntu 32-bit, even though I've 6gigs of ram, hence the mem free being so low. All I have open when running this is 14 chrome tabs.
 
lspci:
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
 

 

Regarding the parked CPU, would this still be an issue if I don't limit frames and just let it run full boar at 700fps? Because the same stuttering issue occurs with or without Vsync enabled.

 

As for energy settings in Linux I have tried using cpu management tools to set the power to performance or else maxing out the CPU. Same for windows with high performance setting.

 

I have also tried setting task priority to very high in Linux and real time in Windows to no avail. Exact same stuttering in the exact same way.


Edited by martinis_shaken, 29 November 2013 - 09:03 AM.


#33 DvDmanDT   Members   -  Reputation: 834

Like
0Likes
Like

Posted 29 November 2013 - 10:31 AM

Hmm, on Linux, have you ever tried LTTng? It basically creates a recording of your system activity which you can then view using tools like LTTv or an Eclipse plugin. Using that, you might be able to get a better understanding of what actually happens. You can see stuff like interrupts, syscalls and more. Maybe some high-prio process/task comes in, maybe there is some other driver doing something funky, etc.

 

I personally don't have a non-virtual Linux system which I can run it on and I also don't have stuff setup for SDL and or OpenGL on my development machines, so I can't really try to reproduce it at the moment.

 

About CPU parking, I don't really know honestly. All I know is that it has been known to cause hickups in games etc, so I disabled it early on and haven't looked back since. LTTng _might_ show you if cpu parking is related.



#34 wintertime   Members   -  Reputation: 1640

Like
1Likes
Like

Posted 29 November 2013 - 10:51 AM


All I have open when running this is 14 chrome tabs.

And you still wonder about a little stuttering? Probably the browser/some flash thingy needs a little CPU shortly.



#35 martinis_shaken   Members   -  Reputation: 145

Like
0Likes
Like

Posted 29 November 2013 - 11:03 AM

Hmm, on Linux, have you ever tried LTTng? It basically creates a recording of your system activity which you can then view using tools like LTTv or an Eclipse plugin. Using that, you might be able to get a better understanding of what actually happens. You can see stuff like interrupts, syscalls and more. Maybe some high-prio process/task comes in, maybe there is some other driver doing something funky, etc.

 

I personally don't have a non-virtual Linux system which I can run it on and I also don't have stuff setup for SDL and or OpenGL on my development machines, so I can't really try to reproduce it at the moment.

 

About CPU parking, I don't really know honestly. All I know is that it has been known to cause hickups in games etc, so I disabled it early on and haven't looked back since. LTTng _might_ show you if cpu parking is related.

 

Just tried out LTTng and it dumped 60MB of data (which babeltrace spits out to my stdout) for only 10 second of gameplay. Wow. May install Eclipse to try and interpret the trace data. Tried plugging it all into an IDE when I set it up with visual studio, but trace data there didn't seem to help. The most valuable trace information so far is what I've posted in some other posts where I've screens that show how long each frame takes using c++11 chrono. I can't imagine system calls and other processes really interfering with the code, given that it happens the same way across multiple systems at the same times. I tried recording it to post a video, but it seems my computer can't handle that. Will try fraps or something in Windows and see if I can record with that.



#36 DvDmanDT   Members   -  Reputation: 834

Like
0Likes
Like

Posted 29 November 2013 - 12:06 PM

LTTng can indeed create alot of data if there's alot of things going on. :) You will most likely want to use some visualizer in order to make sense of it. The Eclipse plugin can apparently also be run standalone. Tracing is one of the best ways to debug these sorts of issues since you get history and in this case also a wider perspective (full OS).






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS