[osg-users] osgscreencapture to videobuffer async

Robert Osfield robert.osfield at gmail.com
Fri Sep 26 01:26:09 PDT 2008


Hi Ralf,

>From my experience with writing osgscreencapture PBO readback is very
very sensitive to frame buffer format and the image format you read
back - only RGBA frame buffer really worked from my under Linux, but
this is type of issue that is very sensitive to the drivers.  Further
to this restriction PBO read back also only provides good performance
if you double buffer, I found a single buffer PBO worse than just a
plain glReadPixels.

So tweak your frame buffer and your image formats to see if you get
get good performance, you can use the osgscreencapture example to
iterate.

Robert.

On Thu, Sep 25, 2008 at 8:23 PM, Ralf Stokholm <alfmail1 at arenalogic.com> wrote:
> Hi Robert / Jean
>
> Thanks for the responce
>
> I realise that glReadPixel has to be called by the drawthread, but as I
> understand it the advantage in using pixel buffer objects should be that
> glReadPixel would be async and therefore return in wery short time.
>
> The actual download and cost is then put on the glMapBuffer call.
>
> If this (glMapBuffer) was possible to do this in another thread then it
> would safe me 5-6 ms in my primary thread. If this is not possible then the
> value of the async glReadPixel seams to fall. Especially since it in many
> cases seams to be a bit slower than a simple glReadPixel;
>
> Brgs.
>
> Ralf
>
> 2008/9/25 Robert Osfield <robert.osfield at gmail.com>
>>
>> Hi Ralf,
>>
>> You can only do the glReadPixel call from the graphics thread so you
>> can't thread this, all you can do is hide the cost of download from
>> the GPU by using a double buffered PBO, as the osgscreencapture
>> example illustrates.  To thread the writing of data you'll need to
>> have a ring buffer of imagers that the draw thread writes to, and a
>> background writing thread reads from.
>>
>> Robert.
>>
>> On Thu, Sep 25, 2008 at 2:57 PM, Ralf Stokholm <alfmail1 at arenalogic.com>
>> wrote:
>> > Hi All
>> >
>> > In our application we have added the option of capturing video from our
>> > playback stream. It works fine but performance is problematic. We are
>> > currently using a simple glReadPixels call to get the immage from the
>> > videocard, this takes around 5-6 ms in addition we append the immage to
>> > an
>> > AVI video stream this takes another 12 ms. It should be possible to put
>> > the
>> > 12 in another thread, but I was vondering if it would be possible to do
>> > the
>> > same with part of the glReadPixels call using PBO's.
>> >
>> > This is what I have in mind:
>> >
>> > From the Draw thread on initialrendercallback I would:
>> >
>> > glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, read_pbo)
>> > glReadPixels() //ASYNC
>> > SignalVideoThread() //Async
>> >
>> > and the in the video recorder thread when signaled
>> >
>> >
>> > glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, copy_pbo);
>> > GLubyte* src =
>> > (GLubyte*)ext->glMapBuffer(GL_PIXEL_PACK_BUFFER_ARB,GL_READ_ONLY_ARB);
>> > AVIStream.addframe(src)
>> > glUnmapBuffer(GL_PIXEL_PACK_BUFFER_ARB);
>> > glBindBuffer(GL_PIXEL_PACK_BUFFER_ARB, 0);
>> >
>> > Can someone tell me if this is feasable?, I was thinking that it would
>> > be
>> > problematic to do the gl calls from another thread? or should I use a
>> > compleately different approach?
>> >
>> > This is run on windowsXP, Core2 quad, Nvidia GX280
>> >
>> > Brgs.
>> >
>> > Ralf Stokholm
>> > Arenalogic
>> > www.arenalogic.com
>> > _______________________________________________
>> > osg-users mailing list
>> > osg-users at lists.openscenegraph.org
>> >
>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >
>> >
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>



More information about the osg-users mailing list