Hi Tim,

I'll have another look at your submission tomorrow and have a think
about the issue.

Robert.

On Mon, Nov 8, 2010 at 8:57 AM, Tim Moore <[email protected]> wrote:
> 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
>
>
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to