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.
That's a good point. The timing was somewhat ironic, too. The same day you sent this message, I was at a GLSL seminar in Portland by Randi Rost (3dlabs). During one of the breaks, the issue of "time" in OpenGL came up. We had a bit of a side discussion about apps that need to be real-time (i.e., hit a target framerate no matter what). Other than WGL_I3D_swap_frame_usage / GLX_MESA_swap_frame_usage, there isn't anything in OpenGL to help applications with this problem.
This is the "Load Monitoring" problem from your original e-mail. My mind is pretty well stuck in the "Tuning" problem. In truth, there really isn't anything in OpenGL to help with either problem. :(
http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/docs/MESA_swap_frame_usage.spec?view=markup http://oss.sgi.com/projects/ogl-sample/registry/I3D/wgl_swap_frame_usage.txt
| ... 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.
I think this is one of the main differences between solving the "Load Monitoring" problem and the "Tuning" problem. The former problem requires real-time data collection and on-line analysis. The later does not require real-time data collection and prefers off-line analysis. SGIX_instruments would work for on-line analysis, and a driver streaming XML to a pipe / file / network connection would work for off-line.
| 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.
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
