diff options
| author | Joe Rayhawk <jrayhawk@freedesktop.org> | 2013-04-14 00:03:00 -0700 |
|---|---|---|
| committer | Joe Rayhawk <jrayhawk@freedesktop.org> | 2013-04-14 00:03:00 -0700 |
| commit | 9f6797a814e88695f0816bb9a5f2b6bd90208098 (patch) | |
| tree | 403904b77df9d95a60855fcf6e24cacade1e85f2 /IntelPerformanceTuning.mdwn | |
| parent | 6a13e76d94d60db1e07639785e539318925bec9e (diff) | |
moin2iki: Redoing a bunch of preformatted text and lists that moin2mdwn kinda screwed up
Diffstat (limited to 'IntelPerformanceTuning.mdwn')
| -rw-r--r-- | IntelPerformanceTuning.mdwn | 53 |
1 files changed, 23 insertions, 30 deletions
diff --git a/IntelPerformanceTuning.mdwn b/IntelPerformanceTuning.mdwn index 087901a..61a3a99 100644 --- a/IntelPerformanceTuning.mdwn +++ b/IntelPerformanceTuning.mdwn @@ -50,48 +50,41 @@ On the other hand, if intel_gpu_top doesn't show the GPU very busy, then you're Not all stalls on the GPU are recorded in `INTEL_DEBUG=perf`. To see all cases where this happens, use the `perf` tool from the Linux kernel (note: unrelated to `INTEL_DEBUG=perf`). + sudo perf record -f -g -e i915:i915_gem_request_wait_begin -c 1 openarena -[[!format txt """ -sudo perf record -f -g -e i915:i915_gem_request_wait_begin -c 1 openarena -"""]] If you want to see the whole system's stalls for a period of time (very useful!), use the `-a` flag instead of a particular command name. Just `^C` when you're done capturing data. At exit, you'll have `perf.data` in the current directory. You can print out the results with `perf report | less`: -[[!format txt """ - 100.00% openarena [vdso] [.] 0x000000ffffe424 - | - |--95.96%-- drm_intel_bo_subdata - | 0xace13d53 - | _mesa_BufferSubDataARB - | _mesa_meta_clear - | 0xace14f86 - | _mesa_Clear - | 0x815d875 - | - --4.04%-- drm_intel_gem_bo_wait_rendering - drm_intel_bo_wait_rendering - | - |--54.67%-- 0xace167e8 - | _mesa_Flush - | glXSwapBuffers - | 0xb774e115 - | SDL_GL_SwapBuffers - | 0x81a4afd - | - -"""]] + 100.00% openarena [vdso] [.] 0x000000ffffe424 + | + |--95.96%-- drm_intel_bo_subdata + | 0xace13d53 + | _mesa_BufferSubDataARB + | _mesa_meta_clear + | 0xace14f86 + | _mesa_Clear + | 0x815d875 + | + --4.04%-- drm_intel_gem_bo_wait_rendering + drm_intel_bo_wait_rendering + | + |--54.67%-- 0xace167e8 + | _mesa_Flush + | glXSwapBuffers + | 0xb774e115 + | SDL_GL_SwapBuffers + | 0x81a4afd + | + This shows that all of the wait events occurred in openarena, and of those, 96% were in `drm_intel_bo_subdata` triggered by `_mesa_Clear` (many `_mesa_Whatever` functions are the implementation of `glWhatever` -- the actual `glWhatever` function is a runtime-generated stub so it doesn't get labeled in profiles). This shows a driver bug -- the `_mesa_meta_clear()` function is calling `_mesa_BufferSubDataARB()` on a buffer currently in use by the GPU, so the CPU blocks waiting for the GPU to finish. The stalls under `glXSwapBuffers` in that trace are desired and expected: you don't want your application to run ahead and request draw 1000 frames of the same time in the game, when it will take a minute to render them all, so the driver stalls you when a whole frame is already queued up for rendering and not started rendering yet. If you want to see exactly where in the compiled code a wait occurred, you can use `perf annotate`: - -[[!format txt """ -perf annotate _mesa_meta_clear -"""]] + perf annotate _mesa_meta_clear ## Some common problems to find |