On Mon, Nov 08, 2004 at 04:56:15PM -0800, Ian Romanick wrote: | The biggest problem with any profiling technique like this is that it is | very, very intrusive to the source code of the application. ...
Well, there are several classes of apps that need immediate performance feedback to determine how to behave. Those include games and simulators, of course, but they also include non-realtime apps that want to measure performance to decide which of several rendering paths to use. (It seems likely to me that some desktop libraries will fall into the latter class.) For those apps, instrumentation isn't intrusive; it's a fundamental part of how they work. | ... This would be like putting code in an app to do | RDTSC (or other MSR reading) to do x86 instruction profiling. ... | ... People much prefer to use tools like oprofile | or VTune. You need hardware-friendly low-level mechanisms to implement user-friendly high-level tools that will do something correct and useful. I thought the SGIX_instruments stuff would be helpful because it makes suggestions about design (e.g. measurement intervals, labelling, asynchronous data delivery, accuracy) and things that are worth measuring (e.g. command counts, data transfer sizes). But maybe not. | The other really big problem with that type of profiling for GL is that | only the application writer can use it. ... SGIX_instruments restricts queries to the current context. But if you're willing to do the necessary locking in the driver and/or hardware, you can make queries on behalf of other contexts (or of performance across all contexts). That's a problem you have to solve for external profilers, too, so I don't think it's a make-or-break issue. Allen ------------------------------------------------------- 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
