Hi Robert,
Robert Osfield wrote:
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.
Well, I'm glad I at least got some reply. I'll keep pushing. The problem
was actually reported earlier (albeit a bit cryptically) on the forums
as well, but there were no responses.
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.
I agree that this would be the most general and complicated solution. It
would take care of everything without user intervention, but I'm trying
to think if there could be some explicit way for a user to set this up
in a graph like manner. E.g. I know that I want X render passes and I
want to generate Y textures, but I might only need a limited number of
cameras (<X and <Y) and hence FBOs. I would somehow like to reuse
cameras. I'm not sure if this kind of reuse is used in other parts of
OSG. If not, then I should stop promising myself to look at osgPPU and
actually look at it, maybe it is the best place to cater for this type
of use.
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.
Couldn't agree more. I can accept that there is a limit, but given the
same hardware, the OS and drivers should not influence this limit. I'll
aim to get the driver fixed before wondering about workarounds any further.
jp
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
--
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
