On Mon, 2004-11-08 at 11:32 -0800, Ian Romanick wrote: > Owen Taylor wrote: > > Over a last few days, I've been working on a tool to allow watching > > a live view of the texture usage of a DRI application. I'm not going to > > go into a lot of detail here - there is a more complete description at: > > > > http://fishsoup.net/software/texturetop/ > > > > And an even more complete README files linked to from here, but the 10 > > second description of the change to the DRI source code is this: > > This is something I've been thinking about ever since I saw the > profiling tools in Nvidia's drivers at SIGGRAPH. There's a LOT of > information that would be useful to get out of the driver about performance: > > - texture use / abuse > - number of primitives in each begin / end block > - operations causing stalls in the driver (e.g., places where the > driver has to explicitly wait on the hardware). > - time to render each frame > - etc. > > We could emit this data as a per-frame (where a frame ends with a > SwapBuffers call on a double buffered visual or glFinish on a single > buffered visual) XML document. Each context would have a named pipe > where some app could read the data. > > I hadn't really thought it through enough (or had time to work on it) to > make worth posting to the list about it. It sounds like your texturetop > interface is in a similar vein
Yes, it's very much along those lines, though if you think of it as:
app =(A)=> profile thread =(B)=> profiler
I've designed things so lots of data gets pushed across (A), the
profiler thread aggregates, and (B) is low bandwidth. The profiler can
poll as infrequently as it likes. So you wouldn't want to accumulate
per-frame data, since it could grow without bound.
But I don't think that's a big problem. You can report data when polled
only for the last frame. Or you can report min/max/average data for
frames since the profiler last polled.
Regards,
Owen
signature.asc
Description: This is a digitally signed message part
