Tiny stutters about example HOT 10 CLOSED

It is indeed fixed in OS X 10.11 El Capitan (the final public release), so pprof can be used reliably.

from example.

That doesn't sound normal and should not happen for such simple examples. If it happens with GOGC=off, then it's definitely not GC.

What video card and CPU do you have? Is your El Capitan version 10.11.2? Which example are you running? Does it happen with both examples?

from example.

It's an Intel Iris 6100 on OS X 10.11.2. It seemed to happen on both examples. I did a bit of diagnostics and it appears the OpenGL 4.1 demo had a bit more difficulty, frame times in the e.g. 10-12ms range frequently, sometimes breaking the 60fps border. FWIW, I'm using an external 4k display (60Hz), which generally doesn't struggle, but could be related.

It seemed to clear up later, so I'm not really sure this is reproducible enough to count as a meaningful Issue. I'll keep an eye on things and see whether I can narrow it down enough to be reproducible.

It's entirely possible this was just a condition of limited resources on the host. This issue can be closed until I can verify or reproduce.

@shurcooL -- on a side note, I tried approaching this at first with pprof and quickly realized it wouldn't be very useful since a great deal of the CPU time is in external code. Do you have any advice for profiling within this kind of scope?

from example.

Thanks for providing the details. While I do think that hardware should be powerful enough to drive these 2 simple examples smoothly, having a 4k display is possibly giving it a harder time.

Would you be able to try the same test using a 1080p or smaller resolution screen?

I do want to point out it's not as clear cut as if you had said you're running an Nvidia GeForce 650M at a much smaller resolution. But I'm not dismissing it, just sharing observations.

on a side note, I tried approaching this at first with pprof and quickly realized it wouldn't be very useful since a great deal of the CPU time is in external code. Do you have any advice for profiling within this kind of scope?

I don't think I can suggest anything specific; I haven't had a chance (nor the need) to profile graphics code in Go very often so far, it has been quite smooth for me. You should start with the basic tools like pprof, but if they're not very helpful, I'm not sure what the next step would be. If you're running pprof on OS X, make sure you're not hitting a bug with it. I'm not sure if it's been fixed by now. https://github.com/rsc/pprof_mac_fix

According to rsc/pprof_mac_fix@c85105a, it may be fixed by now, but that should be confirmed.

from example.

Closing for now, since this issue seems very specific to your hardware. We can reopen if we get a reproducer.

Thanks for reporting though because it means others can hopefully find this issue here if they encounter it!

from example.

OK! I have observed this on my hardware. Just required that I look closely enough. Seems to happen every ten seconds. I'm seeing it on a powerful rig with an Nvidia 1080 GTX and powerful CPU.

• I'm using the gl41core-cube example for testing
• It's visible with glfw.SwapInterval(0) and a framerate > 10,000/sec
• It happens with GOGC=off
• Measuring the time elapsed between frames I always see times < 1ms

I'm not sure what's going on here. I'm wondering if this is anything go specific. Given that the elapsed times between frames are consistently under 1ms and the visual artefacts don't seem correlated to any framerate drop or elapsed frame differences I'm wondering if the problem is in go-gl or at some other layer.

@shurcooL: Can you confirm, if you run the examples and stare at them that they are buttery smooth? It is only just perceptible. It seems as though the spinning cube judders slightly, maybe going backwards. I wish I had a high speed video camera to measure it...

Now I'm off to hunt an example from glfw3 in C to see if this is just a thing that happens in general and I have only just become aware of it.

from example.

Well, it happens for me in the gears example found in the glfw repository. So I guess this must be a "feature" of either glfw or my system.

I'll leave this open for a little bit, but if six months passes and nothing happens then I think this should be closed. It would be interesting to follow up upstream to see if there anyone else has complained over there.

from example.

Yes, I think I see some tiny stuttering, but only with v-sync off. It's not there with v-sync on, on a 60 Hz display.

I tried adding a printf if a given frame takes too long:

if elapsed >= 0.020 {
	fmt.Println(elapsed)
}

And surprisingly I get a few matches (not counting the first frame):

0.025746207999999937
0.03162123499999936
0.030519868999999034

from example.

Just adding more information so that maybe it helps:
Running with kernel: Darwin MacBook-Pro.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
Go version: go version go1.7.4 darwin/amd64

I have not seen such a problem so far.

from example.

I see it with vsync on or off. I also measured the frame latency, and found that the longest frames (per second) were consistently small, even when there was a tiny stutter. So I guess this is a problem elsewhere in the graphics stack than glfw. I'm going to close this for now unless anyone comes up with more information since I don't think there is anything to be done for go-gl here.

from example.