Profiling on OSX High Sierra

Started by mudlee, April 07, 2018, 19:33:09

Previous topic - Next topic

mudlee

Hey!

I'm still experiencing with opengl, polishing my engine as a hobby. I've managed to render 10 millions of cubes with 300+ FPS, tried lots of technics, and now researching terrain generation. For first I just created a 300*300 sized simplex noised terrain, it simply just runs around 4000+ FPS on my 7years old PC with a Geforce GTX 1080 GPU using CentOS.

I just wanted to check program on my 2018 macbook pro, and I was shocked as it produced 5FPS only. I researched and found that lots of the developers say that the problem came with High Sierra.

So I wanted to start a debug/profiling if I can find something that slows the rendering down. I downloaded the Apple's OpenGL profiler app, started my "game" and tried to attach to profiler to the running java. I got this: https://gist.github.com/mudlee/1aa8c9edb6d12e3a1b037e1929c88943.

Do you have any idea, how can I debug or what might causes the problem?

Thanks for your help.

Ps: this is the app I'm running: https://www.youtube.com/watch?v=P252ZSnVAWU&t=0s&list=PLTWVHWBDE0eAAlZpzvc88Hl8C3U9lIOG4&index=5

CoDi

Yeah, GL debugging is in a sorry state on OS X.

They broke their GL profiler a couple of updates ago - though, as weird as it sounds, I've had success connecting it "remotely" (on the same machine, just using the remote connection feature). Didn't try again since then, so I'm not sure if this still works with the latest OS version.

Other than that, I've been using apitrace in the past to figure out some issues/bottlenecks on both MacOS and Windows.

mudlee

thx! Will look into it.
With manual debug however I've found that the glfwSwapBuffers is the slow stuff. If I measure all the other gl call, everything runs superfast until glfwSwapBuffers is called.

KaiHH

To my knowledge, that may not mean anything. Drivers can postpone/defer/queue the actual processing of the GL calls until their effect must be known, which is at glfwSwapBuffers() or glFinish() or other calls such as glReadPixels() when you are reading the backbuffer which you previously rendered to. In addition, the GPU will start processing the GL calls and will do this asynchornously to your CPU/host program. Only at glfwSwapBuffers() and glFinish() will the GPU and CPU synchronize (and in most cases the CPU wait for the GPU to finish).
If you want to know how long calls take on the GPU, measure the GPU time via timer query objects.

mudlee

Yeah, I found a topic on jgo and it says the same: http://www.java-gaming.org/index.php?;topic=36093.0

Will write when I find the problem :)

mudlee

Codi, how can I use apitrace? it starts the application but does not log anything.
I ran it like:
./build/apitrace trace --api gl --output=TRACE -v java -XstartOnFirstThread -Dorg.lwjgl.util.DebugLoader=true -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.opengl.Display.enableHighDPI=true -Dorg.lwjgl.opengl.Display.enableOSXFullscreenModeAPI=true -jar ../intermetto/target/intermetto-1.0-SNAPSHOT.jar


Quote from: CoDi on April 08, 2018, 16:23:36
Yeah, GL debugging is in a sorry state on OS X.

They broke their GL profiler a couple of updates ago - though, as weird as it sounds, I've had success connecting it "remotely" (on the same machine, just using the remote connection feature). Didn't try again since then, so I'm not sure if this still works with the latest OS version.

Other than that, I've been using apitrace in the past to figure out some issues/bottlenecks on both MacOS and Windows.

mudlee

Thx. Don't want to open an another thread, so I'm asking here. Is there any example how can I use glDebugMessageCallback? Or... am I right when I say it doesnt work, because its from 4.3 and osx has 4.1?

Quote from: KaiHH on April 09, 2018, 18:53:49
To my knowledge, that may not mean anything. Drivers can postpone/defer/queue the actual processing of the GL calls until their effect must be known, which is at glfwSwapBuffers() or glFinish() or other calls such as glReadPixels() when you are reading the backbuffer which you previously rendered to. In addition, the GPU will start processing the GL calls and will do this asynchornously to your CPU/host program. Only at glfwSwapBuffers() and glFinish() will the GPU and CPU synchronize (and in most cases the CPU wait for the GPU to finish).
If you want to know how long calls take on the GPU, measure the GPU time via timer query objects.

CoDi

Quote from: mudlee on April 09, 2018, 19:23:15
Codi, how can I use apitrace? it starts the application but does not log anything.

Uh, to be honest, I "cheated" there and traced a version built with packr - so I had to run a native executable, no Java app. The thread here has some command line examples though.

QuoteIs there any example how can I use glDebugMessageCallback? Or... am I right when I say it doesnt work, because its from 4.3 and osx has 4.1?

It's been supported through various GL extensions before 4.3, but none of those is supported on OS X as far as I know.

mudlee

OK, finally I've found the problem. One line in the shader killed the FPS:
vec3 cameraPosition=(inverse(viewMatrix)*vec4(0.0,0.0,0.0,1.0)).xyz;


The inverse is the method that slows down everything.