Hi Robert, I had a need for the GPU timer support this weekend -- the normal OSG stats were deceiving -- so I reapplied this patch and found it still applies cleanly to current sources. I'd like to do what it takes to get it in, as it is pretty useful.
If I understand correctly from the previous discussion, you like the idea of a GraphicsContext swap callback but don't want it subverted entirely for gathering statistics, and you think that the timer query code should be moved into osg::State (and out of Renderer). If that's correct, I'll rework the patch and resubmit it. Tim On Mon, Aug 16, 2010 at 7:43 PM, Tim Moore <[email protected]> wrote: > > > On Mon, Aug 16, 2010 at 6:26 PM, Robert Osfield > <[email protected]>wrote: > >> Hi Tim, >> >> I am currently reviewing this submission and generally it looks great >> and I'm now thinking about merging various parts of it. I'm not yet >> happy with all parts though, in particular the introduction of graphic >> context swap callback and then use of this in osgViewer::ViewerBase >> feels at overly hardwired and in the longer term inflexible and >> potentially buggy if users feel they want to use the swap callback >> themselves. I'd like to come up with a better solution for this part >> of the feature before merging the complete functionality. >> >> I'm happy with the addition of a swap callback to GraphicsContext, but >> I'd probably look to hide the if (callback) callback else >> swapImplementation within a convenience method so we can centralize >> the implementation details so that GraphicsThread.cpp doesn't need to >> know about specifically about callbacks. Leave this with me to worry >> about the details on this. >> >> I agree and thought of this when I added the swap callback. When I hack on > OSG "internals" there's always a tension about how far to dive into the > heart of the implementation, and here I chose to fritter away at the edges. > >> I would rather not see such a swap callback used for the purpose of >> collecting stats. Perhaps osg::State itself could be called by >> GraphicsContext::swapBuffer or the new convenience method I allude to >> above. Always invoking this call seems inappropriate so I would have >> thought that a flag could be used to enable this type of stats >> collection in osg::State. >> >> Thoughts? >> Robert. >> >> >> The stats collection seemed to me to be linked to osgViewer and friends, > but I'm not tied to any particular approach here. > > I'm thinking about submitting a patch to change the stats to display all > the traversals of a single frame in the same color, instead of grouping > traversals of the same kind. This should help answer some of the questions > about latency that have come up lately. > > Tim > >> >> >> >> >> >> On Thu, Jul 8, 2010 at 10:49 AM, Tim Moore <[email protected]> wrote: >> > Hi, >> > I've implemented using a timestamp, available with ARB_timer_query and >> > OpenGL 3.3, to gather GPU stats. This is nice because it can accurately >> fix >> > the GPU draw time with respect to the other times on the stats graph, >> rather >> > than having to estimate the wall time of the end of GPU drawing. This >> also >> > prevents anomalies like the GPU phase starting before the draw phase... >> > Tim >> > >> > _______________________________________________ >> > osg-submissions mailing list >> > [email protected] >> > >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >> > >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
