On Mon, Nov 08, 2004 at 11:32:24AM -0800, Ian Romanick wrote:
| 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
Have you taken a look at the SGIX_instruments extension? It provides a framework that's intended for gathering profiling information asynchronously. The idea was that you'd add separate extensions that defined the actual instrumentation (SGIX_ir_instrument1 was an early example).
I looked at those extensions once a long time ago. My impression then, and even now at re-examining them, is: Yuck! I have a number of "issues" with those extensions in particular and with similar profiling methods in general. I'll stick to the general issues here. ;)
The biggest problem with any profiling technique like this is that it is very, very intrusive to the source code of the application. The application has to be coded to measure itself, and it has to know what and how to measure. This would be like putting code in an app to do RDTSC (or other MSR reading) to do x86 instruction profiling. It's tough to change what is being measured (e.g., instruction timings, cache misses, etc.), and you end up with a bunch of crap, that quickly becomes outdated, in the source code. People do it, but usually only in limited circumstances (e.g., the measure the performance of one specific routine under controled inputs). People much prefer to use tools like oprofile or VTune.
The other really big problem with that type of profiling for GL is that only the application writer can use it. Presumably all the instrumentation code is removed from the release binaries, so driver writers can't hook profiling information to improve the drivers. Sure, we could put another mechanism in the driver, but then we have two mechanisms that we have to maintain.
Looking at GL profiling from an oprofile point of view, the ideal situation would be to have some sort of GUI (that could be run on a different machine) where the user could select the information to gather, then start recording. The user could then run whatever test they wanted, and stop recording when the test was done. Then a graphics of per-frame statistics could be presented. An obvious choice would be the per-frame time. The user could then select specific frames (or ranges of frames) to view more detailed statistics for that frame.
Obviously, this is a MUCH bigger project than something like texturetop.
------------------------------------------------------- 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
