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:
If the LIBGL_PROFILE_SERVER is set to [HOST]:PORT, then a separate
thread is created that connects to the server and waits for the server to request updates. In request to each UPDATE command, it dumps all the creations/deletions/modifications of the state back to the server via a text-based protoocl.
I've attached the header file for the new internal 'texprof.h' to the mail. It's pretty clean and simple to use ... the changes to the Savage driver to support texture profiling aren't large. That's the only card I've written support for, since I wanted to concentrate on getting the framework working. It may be possible to get a lot of the other cards working at once by adding support to texmem.c.
As far as I know, other than adding support for additional cards, this change is reasonably complete and bug-free. There's a lot of other information that could be reported over the profiling interface, but what is there now seems to work well. (One limitation is that only 2d textures are supported at the moment.)
My questions would be:
- Is this interesting to anybody but me? It's been quite useful to me so far in just the couple of hours I've had it working...
It's definitely interesting. Have you been using it to tune an application, or from the point of view of tuning driver behaviour?
- Does this duplicate something else that is out there already?
Not to my knowledge.
- What's the chance of getting this integrated into the main sources?
I think pretty good. Mesa wraps some things that are called directly by the patch, I'm not sure what the gotchas with libraries creating threads without the applications knowledge are, but if it's only done in response to an environment flag & maybe a compile option, I can't see that being a problem.
It'd be good to let people play around with it a little first, which for me means early in the week, most likely.
Keith
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
