Hi Bruce,

We've tested the same code I posted (the Main.cpp) without modifications.
About the cards, we're using 2 NVidia GTX 285, with the latest drivers from
the NVidia website.

Cheers,

On Sat, Apr 10, 2010 at 10:34 PM, Bruce Wheaton <br...@spearmorgan.com>wrote:

> Thanks for reporting back Serge - glad that's working for you. Sorry I
> didn't have time to test on my Linux rig.
>
> Was the technique the same as your Main.cpp example, as posted, or did you
> have to do any extra tricks?
>
> Also, what graphics cards and drivers are you using? That makes a big
> difference in Linux.
>
> Regards,
>
> Bruce Wheaton
>
>
> On Mar 29, 2010, at 5:17 AM, Serge Lages wrote:
>
> Hi all,
>
> Some news on this topic, we've tested on Linux : same hardware (2 GTX285
> and 4 screens), same video, same code, an ubuntu 9.04 configured with 4
> screens, with VSync enabled we've got a solid 60fps... Without VSync it goes
> between 150 and 300fps.
>
> So we've got our solution, we'll make our setup on Linux. Multi-screen
> support in OpenGL is really crappy on Windows... :/
>
> Cheers,
>
> On Thu, Mar 25, 2010 at 2:44 PM, Serge Lages <serge.la...@gmail.com>wrote:
>
>> Hi JP,
>>
>> Thanks for your reply, we've tested to share the contexts but it wasn't
>> much better.
>>
>> Cheers,
>>
>>
>> On Thu, Mar 25, 2010 at 9:24 AM, J.P. Delport <jpdelp...@csir.co.za>wrote:
>>
>>> Hi Serge,
>>>
>>> Serge Lages wrote:
>>>
>>>> Hi all,
>>>>
>>>> Still having problems playing my big video. Here is our current state :
>>>>
>>>> - On a single screen setup (with only one GT 220 GeForce), with a
>>>> composite viewer and 4 windows (450x800 each window), it plays smoothly at
>>>> 60 fps with a fluid video, no problem here.
>>>> - On the destination setup : Intel QuadCore + 2 GeForce GTX 285 + 4
>>>> screens in 1360x768 (2 screens per cards), a composite viewer with one view
>>>> per screen, it plays between 10 and 20 fps... We've made our tests on WinXP
>>>> and Win7 with the same result.
>>>>
>>>> The technique we're currently using is the one from Robert, having a big
>>>> osg::Image updated by ffmpeg, and having 4 images for the textures pointing
>>>> at the correct location on the large one. The video's size is 768x6532.
>>>>
>>>
>>> Have you tried sharing the context for the two views per card? Also, you
>>> are now uploading twice the data needed to each GPU, because each one is
>>> only viewing half the data. I'm sorry I can't help further currently, I
>>> would love to test on Linux, but don't have time...
>>>
>>> jp
>>>
>>>
>>>> You can find attached the current code, any idea on what can be better ?
>>>> Or any other idea on how to handle this problem ? And any chance for 
>>>> someone
>>>> to test on Linux ?
>>>> You can also find the test video here :
>>>> http://labs.tharsis-software.com/outv.mp4
>>>>
>>>> Thanks !
>>>>
>>>> On Thu, Mar 11, 2010 at 9:53 AM, Serge Lages <serge.la...@gmail.com<mailto:
>>>> serge.la...@gmail.com>> wrote:
>>>>
>>>>    Hi all,
>>>>
>>>>    Thanks for your advices. About the current setup, we're using only
>>>>    one screen with a 9800GT card (and 4 windows) for our tests, but the
>>>>    final setup will be composed of 2 9800GT cards and 4 screens.
>>>>
>>>>    I'll let you know how our tests goes.
>>>>    Cheers,
>>>>
>>>>
>>>>    On Thu, Mar 11, 2010 at 8:28 AM, J.P. Delport <jpdelp...@csir.co.za
>>>>     <mailto:jpdelp...@csir.co.za>> wrote:
>>>>
>>>>        Hi,
>>>>
>>>>
>>>>        Serge Lages wrote:
>>>>
>>>>            Hi JP,
>>>>
>>>>            Thanks for your answer, and we don't need sound. By a "fast
>>>>            disk", what do you recommend ?
>>>>
>>>>
>>>>        We have a raid0 setup that can sustain 150MB/s.
>>>>
>>>>
>>>>            Your ffmpeg reader is based on the current OSG plugin or is
>>>>            it a custom one ?
>>>>
>>>>
>>>>        It's a custom one, but not complicated. It basically pops the
>>>>        output of ffmpeg decompress into an osg::Image, set's PBO on
>>>>        that and lets OSG upload it. We are using only monochrome images
>>>>        though (GL_LUMINANCE).
>>>>
>>>>
>>>>
>>>>            About our file, with some codecs and adjustments on the
>>>>            bitrate, we're able to play it with VLC without problems, so
>>>>            I think the reading part can be handled by the ffmpeg plugin
>>>>            with only one file, but then we need to dispatch this image
>>>>            on 4 textures. We're currently trying to do some tests.
>>>>
>>>>
>>>>        I'm still not sure where your problem area is. If it's not
>>>>        decoding it can only be upload to GPU or final rendering. You
>>>>        should be able to check this by varying the complexity of the
>>>>        rendering.
>>>>
>>>>        jp
>>>>
>>>>
>>>>            Cheers,
>>>>
>>>>
>>>>            On Wed, Mar 10, 2010 at 4:53 PM, J.P. Delport
>>>>            <jpdelp...@csir.co.za <mailto:jpdelp...@csir.co.za>
>>>>             <mailto:jpdelp...@csir.co.za <mailto:jpdelp...@csir.co.za
>>>> >>>
>>>>
>>>>            wrote:
>>>>
>>>>               Hi Serge,
>>>>
>>>>
>>>>
>>>>
>>>>               Serge Lages wrote:
>>>>
>>>>                   Hi all,
>>>>
>>>>                   We currently need to play a big video (approximately
>>>>            5500*800)
>>>>                   on 4 screens within an OSG application (we use a
>>>>            composite
>>>>                   viewer), so we've tried :
>>>>
>>>>                   - Cut the video in 4 parts, but it seems really hard
>>>> to
>>>>                   synchronize the 4 streams.
>>>>                   - Decode directly the big file, resulting with a very
>>>> big
>>>>                   texture split on 4 quads (with appropriate texture
>>>>            coords), but
>>>>                   even with a powerful computer, it's very slow.
>>>>
>>>>                   Any idea on what's the best approach for this problem
>>>>            ? We're
>>>>                   currently making our tests using the ffmpeg plugin,
>>>>            but maybe
>>>>                   another plugin would be more appropriate ?
>>>>                   Thanks in advance for your help.
>>>>
>>>>
>>>>               some ideas/questions. We do something similar - stitch
>>>>            four high-res
>>>>               camera videos into large texture. We have custom ffmpeg
>>>>            reader that
>>>>               just reads from 4 video files and we step them manually
>>>>            (and in
>>>>               sync) one frame at a time. We use raw video (no
>>>>            compression) to
>>>>               avoid cpu decompress, but now one needs fast disks. We
>>>>            don't have
>>>>               sound, do you need sound? For large sizes one needs to
>>>>            avoid copying
>>>>               around data in cpu mem as much as possible. There is
>>>>            still one copy
>>>>               in ffmpeg raw read that I need to get rid of.
>>>>
>>>>               rgds
>>>>               jp
>>>>
>>>>
>>>>                   Cheers,
>>>>
>>>>                   --         Serge Lages
>>>>                   http://www.tharsis-software.com
>>>>
>>>>
>>>>
>>>>  ------------------------------------------------------------------------
>>>>
>>>>                   _______________________________________________
>>>>                   osg-users mailing list
>>>>                   osg-users@lists.openscenegraph.org
>>>>            <mailto:osg-users@lists.openscenegraph.org>
>>>>                   <mailto:osg-users@lists.openscenegraph.org
>>>>            <mailto:osg-users@lists.openscenegraph.org>>
>>>>
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>               --     This message is subject to the CSIR's copyright
>>>>            terms and
>>>>               conditions, e-mail legal notice, and implemented Open
>>>>            Document
>>>>               Format (ODF) standard. The full disclaimer details can be
>>>>            found at
>>>>               http://www.csir.co.za/disclaimer.html.
>>>>
>>>>               This message has been scanned for viruses and dangerous
>>>>            content by
>>>>               MailScanner, and is believed to be clean.  MailScanner
>>>> thanks
>>>>               Transtec Computers for their support.
>>>>
>>>>               _______________________________________________
>>>>               osg-users mailing list
>>>>               osg-users@lists.openscenegraph.org
>>>>            <mailto:osg-users@lists.openscenegraph.org>
>>>>               <mailto:osg-users@lists.openscenegraph.org
>>>>            <mailto:osg-users@lists.openscenegraph.org>>
>>>>
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>
>>>>
>>>>            --             Serge Lages
>>>>            http://www.tharsis-software.com
>>>>
>>>>
>>>>
>>>>  ------------------------------------------------------------------------
>>>>
>>>>            _______________________________________________
>>>>            osg-users mailing list
>>>>            osg-users@lists.openscenegraph.org
>>>>            <mailto:osg-users@lists.openscenegraph.org>
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>        --         This message is subject to the CSIR's copyright terms
>>>> and
>>>>        conditions, e-mail legal notice, and implemented Open Document
>>>>        Format (ODF) standard. The full disclaimer details can be found
>>>>        at http://www.csir.co.za/disclaimer.html.
>>>>
>>>>        This message has been scanned for viruses and dangerous content
>>>>        by MailScanner, and is believed to be clean.  MailScanner thanks
>>>>        Transtec Computers for their support.
>>>>
>>>>        _______________________________________________
>>>>        osg-users mailing list
>>>>        osg-users@lists.openscenegraph.org
>>>>        <mailto:osg-users@lists.openscenegraph.org>
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>>
>>>>
>>>>    --     Serge Lages
>>>>    http://www.tharsis-software.com
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Serge Lages
>>>> http://www.tharsis-software.com
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users@lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>
>>> --
>>> This message is subject to the CSIR's copyright terms and conditions,
>>> e-mail legal notice, and implemented Open Document Format (ODF) standard.
>>> The full disclaimer details can be found at
>>> http://www.csir.co.za/disclaimer.html.
>>>
>>> This message has been scanned for viruses and dangerous content by
>>> MailScanner, and is believed to be clean.  MailScanner thanks Transtec
>>> Computers for their support.
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>>
>> --
>> Serge Lages
>> http://www.tharsis-software.com
>>
>
>
>
> --
> Serge Lages
> http://www.tharsis-software.com
>  _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Serge Lages
http://www.tharsis-software.com
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to