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
