Hi J.P. Thanks for pursuing this. Gotta say I'm a bit unimpressed by the response from the Nvidia engineer, kinda sounds like he hasn't properly read your post or the thread and has placed it under the ignore it's a user problem category.
Rebinding textures with different FBO's is something we could look at but it'll complicate the code significantly - we'd need to maintain a pool of FBO's, and bind them dynamically. While this might be a worthy thing to do if we really want to be throwing tens of thousands of FBO's into the system, but given we already know that Windows and OSX drivers can manage a 1000 FBO's, the need for doing the rebinding is rather moot - this is a driver issue. Robert. On Thu, Nov 27, 2008 at 11:25 AM, J.P. Delport <[EMAIL PROTECTED]> wrote: > Hi all, > > I have some progress to report on this, yay :) > > I did not get a reply after I sent the email to [EMAIL PROTECTED], so > yesterday I posted the same info to the nvnews forum. > > http://www.nvnews.net/vbulletin/showthread.php?p=1856407 > > I received a reply within 24 hours, see below: > > ----8<---- > jamesjones > NVIDIA Corporation > > FBO's are a limited resource. Do you really need hundreds of FBO's or do you > just need to render to 100's of textures/renderbuffers? If the latter, > change your FBO's textures rather than creating so many FBO's. There is a > slight performance penalty for changing FBO bindings, but it shouldn't be > too bad. > > If you really need an unbounded number of FBO's, that's not gonna work. We > can modify the limit, but you'd have to give us a good reason to. > > The X errors, however, are a bug. That should be fixed in r180. The only > side effect of creating too many FBO's should be a GL_OUT_OF_MEMORY error > and bad framebuffer status. > ----8<---- > > I believe the first point is quite valid and one can try to limit the number > of FBOs created. Doing the rebinding might be a bit challenging using > current OSG, but maybe we can streamline the process. I can look at this, > but any help and ideas are welcome. Does anyone know if OSGPPU supports the > rebinding in an easy to use way? Art? > > I understand that an unbounded number might not be possible, but I'd like an > app that works on Windows to also work on Linux, so I'd like the limit to at > least be the same. Anyone have any other reasons I can put forward? > > I'm going to try r180 asap and will report any changes. > > regards > jp > > J.P. Delport wrote: >> >> Hi all, >> >> I've sent a bug report regarding the FBO problems under Linux to >> [EMAIL PROTECTED] >> >> Will report back if I hear anything. I am not yet registered with NVidia >> so could not use the web form, but I hope the email will get somewhere. >> >> jp >> >> -------- Original Message -------- >> Subject: Unable to create many (>300) FBOs under Linux >> Date: Tue, 18 Nov 2008 15:43:11 +0200 >> From: J.P. Delport <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> >> Good day, >> >> we are trying to implement an image processing application using OpenGL >> and OpenSceneGraph. Recenly one of our algorithms that require many FBOs >> failed to run under Linux. The same code works fine under Windows. >> >> I have attached a simple example that recreates the same errors on both >> a Laptop with a GeForce Go 7400 and a desktop machine with a GTX280. >> >> See the fbo_test.tgz file. The readme explains how to compile and run >> the test application. >> >> The errors from the two machines are in fbo_test_Go7400.txt and >> fbo_test_GTX280.txt. >> >> The nvidia-bug-report from the two machines are also attached. >> >> The application was modified from a same problem report on the forums, >> see here: >> >> http://www.nvnews.net/vbulletin/showthread.php?t=88178 >> >> The issue has also been discussed on the OpenSceneGraph mailing list in >> the following threads: >> >> http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/35229/ >> >> http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/35411/ >> >> The osgmemorytest example was run by quite a few people and displayed >> similar problems on a variety of Linux/NVidia machines. The >> osgmemorytest example also manages to kill the X server on occasion. >> >> A typical error report from osgmemorytest: >> >> osgmemorytest --window --fbo 512 512 -g 300 >> iteration 0 >> Got an X11ErrorHandling call display=0x80c3418 event=0xbfe574d0 >> BadAlloc (insufficient resources for operation) >> Major opcode: 143 >> Minor opcode: 27 >> Error code: 11 >> Request serial: 2848 >> Current serial: 2849 >> ResourceID: 48234499 >> Got an X11ErrorHandling call display=0x80c3418 event=0xbfe57530 >> BadDrawable (invalid Pixmap or Window parameter) >> Major opcode: 145 >> Minor opcode: 4 >> Error code: 9 >> Request serial: 2849 >> Current serial: 2849 >> ResourceID: 48234499 >> Warning: detected OpenGL error 'out of memory' after applying attribute >> FrameBufferObject 0x80aa470 >> >> Any information regarding this problem would be welcomed. Also please >> contact me if further information is required. >> >> regards >> J.P. Delport >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
