[Intel-gfx] INSTDONE instrumentation (patch in progress)

Peter Clifton pcjc2 at cam.ac.uk
Sun Oct 31 03:24:06 CET 2010

Hi guys,

I thought I'd attach this, as it is now gone 2AM and I doubt I'm going
to finish it "tonight". I was hoping to elicit some initial review to
suggest whether the design was sane or not.

I'd originally imagined tying the profiling lifetime to the execution /
completion of individual batch-buffers, but for now I'd like to get it
partly working like this, and perhaps develop some user-space program to
view the results and see if they make sense.

The basic (kernel side) functionality is there, albeit limited by some
hard-coded timing parameters and buffer sizes. I might look at whether
it makes sense to do some in-kernel over-sampling and percentage
generation, or just spit raw register dumps out to the debugfs interface
for userspace to do that. (Buffer size might play a part in that

The locking is a little rough, and I probably need to double-buffer the
sample buffers so I can always be sure the debugfs inteface gets a
complete "frame" / "buffer" / whatever.. trace's worth of data. Perhaps
I should put a semaphore around the debug data output which sleeps until
the profiling has been stopped. (E.g. at the end of a frame).

Currently the debugfs routine just takes a spinlock and copies out
whatever samples have been gathered, meaning the only reliable way to
see a full frame's worth of data is for it to be the last frame before
the instrumented client quit. Part of me did wonder about doing a
constant stream of data to userspace.. but then I quickly realised I had
no idea how to do that, and what to do if userspace lets us overrun our
buffers ;)

I've got a libdrm patch to expose the new IOCTL (also attached), but I
don't have a very good solution for hooking that into mesa and
synchronising with frames. I applied a VERY dirty kludge for testing.

Does anyone know if you can pass userdata parameters to a hrtimer? From
the API, it looked not - although in that case, how do you avoid needing
horrid global state variables?


Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Hacky-little-instdone-and-instdone1-profiler.patch
Type: text/x-patch
Size: 15932 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20101031/665f6e9d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Expose-the-IOCTL-for-tracing-the-GPU-s-idle-status.patch
Type: text/x-patch
Size: 4778 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20101031/665f6e9d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesa_hack.patch
Type: text/x-patch
Size: 1111 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20101031/665f6e9d/attachment-0002.bin>

More information about the Intel-gfx mailing list