Re: [osg-users] debugging slow path
Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hi Keith, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. Robert. On Thu, Dec 2, 2010 at 4:30 PM, Keith Parkins kpark...@cs.rochester.edu wrote: Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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 ___ 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
Re: [osg-users] debugging slow path
Hi Robert, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. He could still be using an optimized build and setting breakpoints, as debug information settings are separate from optimization settings, and as long as you're in a Release build, you won't be using the debug STL (which is what destroys OSG's performance in Debug builds - since OSG uses the STL heavily in its traversals and VC++ does extensive/expensive checking of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) We sometimes include debug info in Release builds to be able to debug some problems that happen only in optimized builds. Sometimes the stack traces it gives then is bogus because of the optimization, but it's still useful if you know what to do with it. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hi J-S and Robert, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) Trust me, I'm not going to get into any design arguments. People in glass houses and all . . . . Unless you want to get into some text editor argument (all hail ed!!). Those seem productive. ;-) -K On Thu, 2 Dec 2010, Jean-Sébastien Guay wrote: Hi Robert, I don't know if this is relevant, but for all performance testing you should use an optimized build, debug builds, especially using VS totally destroy performance. He could still be using an optimized build and setting breakpoints, as debug information settings are separate from optimization settings, and as long as you're in a Release build, you won't be using the debug STL (which is what destroys OSG's performance in Debug builds - since OSG uses the STL heavily in its traversals and VC++ does extensive/expensive checking of STL usage at runtime in Debug builds - don't argue that it's a bad thing to do, I agree, but I'm not Microsoft...) We sometimes include debug info in Release builds to be able to debug some problems that happen only in optimized builds. Sometimes the stack traces it gives then is bogus because of the optimization, but it's still useful if you know what to do with it. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ 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
Re: [osg-users] debugging slow path
On Thu, Dec 2, 2010 at 5:30 PM, Keith Parkins kpark...@cs.rochester.eduwrote: Once again, thanks to everyone who has offered help. I ended up setting breakpoints on the five glBegin calls in Geometry.cpp, yet my code doesn't seem to hit any of them. Actually, I meant setting a breakpoint in the actual glBegin function. You won't have the source code to it, of course, but it should still be possible to break at that function. Tim This is running on WindowsXP/NVidia gtx260 (drivers 6.14.12.5721) if that makes a difference. I know when I run stuff on my linux box at home, I have to use fluxbox instead of gnome because gnome kills my frame rate in the same way I am seeing on the WindowsXP box. In gnome, I can run the scene and I'll get horrible ~10fps while in fluxbox it gets ~400fps. Because of hardware requirements, I have to run this on XP. I can't seem to find any other glBegin entry points. Does anyone have any suggestions? I checked to make sure that I wasn't explicitely dirtying the display lists. Thanks again! -K On Wed, 1 Dec 2010, Keith Parkins wrote: Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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 ___ 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
Re: [osg-users] debugging slow path
Hi Keith, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. Ah, so my apologies to Robert, he was right to mention it. I thought that had been mentioned at the beginning of the thread, but it must have been another thread. As both Robert and I said, doing any kind of performance measurement in VC++ in Debug builds will lead to bad results (unrepresentative of the real performance). I've seen cases where the performance from one run to the next was totally different, with no changes to source code, with Debug builds. So try to find out what's slowing down the program in that case... :-) But using a Release build (optimization turned on, Release C++ runtime, Release STL) with debugging symbols turned on (/Z* compiler options and /DEBUG linker option) is fine, performance will be a bit slower but still representative. And another part of the equation is running in the debugger or not. Pressing F5 attaches the debugger, whether in Debug or Release builds. That slows things down a bit too (because the debugger can show you what DLLs have been loaded while it's happening, things like that). Pressing Ctrl-F5 does not attach the debugger, whether in Debug or Release builds. You always have the option to attach it later (when a crash happens, or when you get to the point in your app that you want to trace), by using the Debug - Attach to Process menu option. If doing performance testing, I will use a Release build, no debugging symbols, and press Ctrl-F5 to get accurate results (the same as an end-user would get on my machine). I've seen especially large slowdowns when running in the debugger versus not running in the debugger (even with Release builds) when using boost::persistence, but that's just one example. So in that case I might start with Ctrl-F5, load our data files (which is done with boost::persistence), and then attach the debugger once boost::persistence has finished doing its thing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
J-S and Robert, You rule! That was it. Don't link to debug libraries on Windows -K On Thu, 2 Dec 2010, Jean-Sébastien Guay wrote: Hi Keith, I was using a debug build. I'm trying out a release build, but I am swamped and trying to do a bunch of things. I'll get back sometime in the next day with my results. I'm hoping this is it because the one difference between osgviewer and my app is that I am using debug libs. Ah, so my apologies to Robert, he was right to mention it. I thought that had been mentioned at the beginning of the thread, but it must have been another thread. As both Robert and I said, doing any kind of performance measurement in VC++ in Debug builds will lead to bad results (unrepresentative of the real performance). I've seen cases where the performance from one run to the next was totally different, with no changes to source code, with Debug builds. So try to find out what's slowing down the program in that case... :-) But using a Release build (optimization turned on, Release C++ runtime, Release STL) with debugging symbols turned on (/Z* compiler options and /DEBUG linker option) is fine, performance will be a bit slower but still representative. And another part of the equation is running in the debugger or not. Pressing F5 attaches the debugger, whether in Debug or Release builds. That slows things down a bit too (because the debugger can show you what DLLs have been loaded while it's happening, things like that). Pressing Ctrl-F5 does not attach the debugger, whether in Debug or Release builds. You always have the option to attach it later (when a crash happens, or when you get to the point in your app that you want to trace), by using the Debug - Attach to Process menu option. If doing performance testing, I will use a Release build, no debugging symbols, and press Ctrl-F5 to get accurate results (the same as an end-user would get on my machine). I've seen especially large slowdowns when running in the debugger versus not running in the debugger (even with Release builds) when using boost::persistence, but that's just one example. So in that case I might start with Ctrl-F5, load our data files (which is done with boost::persistence), and then attach the debugger once boost::persistence has finished doing its thing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ 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
Re: [osg-users] debugging slow path
Hello Keith, That was it. Don't link to debug libraries on Windows -K Well, not when testing performance, of course. When you want to do actual debugging, you kind of have to (apart from in some specific cases). Generalities like the above are most often wrong because so many exceptions exist... It always depends on the situation. You're the developer, you make your decisions with hopefully as much information as required to make the right ones. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
On 12/02/2010 01:39 PM, Jean-Sébastien Guay wrote: Generalities like the above are most often wrong because so many exceptions exist... It always depends on the situation. You're the developer, you make your decisions with hopefully as much information as required to make the right ones. One of my favorite axioms: All generalizations are false. ;-) --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
Hi Jason, One of my favorite axioms: All generalizations are false. That's a good one, I'll have to remember it. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] debugging slow path
Hi, My app is currently rendering via the slow path. I've checked for DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose anyone know of other things I should be looking for? I am walking through the rendering stage to see if I can figure out what is getting set that is putting me on the slow track, but I don't have endless amounts of time to do this. If anyone has any understanding of this, I would be most appreciative if you could point me in the right direction. If you need more information, check my post FBO problem? Thanks! Keith PS: Thanks a lot for the help, Jason. On Tue, 30 Nov 2010, Jason Daly wrote: On 11/30/2010 08:09 PM, Keith Parkins wrote: I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL); and I did see a model with NormalBinding PER_VERTEX. Should I be setting these to BIND_OFF or is it just BIND_PER_PRIMITIVE? No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not sure why you'd be falling off the fast path. There may be other reasons for it, but I can't think of them... --J ___ 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
Re: [osg-users] debugging slow path
So I added a nodevisitor to traverse my scene like so:
class checkFastPath : public osg::NodeVisitor {
public:
checkFastPath() :
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}
virtual void apply(osg::Geode geode) {
for(unsigned int i=0;igeode.getNumDrawables();++i) {
osg::Geometry*geometry =
geode.getDrawable(i)-asGeometry();
if (geometry) {
std::string name = geometry-getName();
if (!geometry-areFastPathsUsed())
std::cout name is not using fast path\n;
}
}
}
checkFastPath fptest;
getSceneData()-accept(fptest);
Nothing comes up. I did have an else on this test
(!geometry-areFastPathsUsed()) to make sure that I was hitting the
conditional. I did the same test before quitting and nothing comes up,
neither after initialization nor at the end.
Any ideas? Are there any other roads to the short path?
On Wed, 1 Dec 2010, Keith Parkins wrote:
Hi,
My app is currently rendering via the slow path. I've checked for
DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either.
Dose anyone know of other things I should be looking for? I am walking
through the rendering stage to see if I can figure out what is getting set
that is putting me on the slow track, but I don't have endless amounts of
time to do this. If anyone has any understanding of this, I would be most
appreciative if you could point me in the right direction.
If you need more information, check my post FBO problem?
Thanks!
Keith
PS: Thanks a lot for the help, Jason.
On Tue, 30 Nov 2010, Jason Daly wrote:
On 11/30/2010 08:09 PM, Keith Parkins wrote:
I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL);
and I did see a model with NormalBinding PER_VERTEX. Should I be
setting
these to BIND_OFF or is it just BIND_PER_PRIMITIVE?
No, BIND_PER_PRIMITIVE is the bad binding. All of the others are
fine. If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes,
I'm not sure why you'd be falling off the fast path. There may be other
reasons for it, but I can't think of them...
--J
___
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] debugging slow path
You could set a breakpoint on glBegin() in a debugger and see where it is
called from OSG.Once there you should be able to figure out why you are
falling off the fast path.
Tim
On Wed, Dec 1, 2010 at 6:35 PM, Keith Parkins kpark...@cs.rochester.eduwrote:
So I added a nodevisitor to traverse my scene like so:
class checkFastPath : public osg::NodeVisitor {
public:
checkFastPath() :
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN) {}
virtual void apply(osg::Geode geode) {
for(unsigned int i=0;igeode.getNumDrawables();++i) {
osg::Geometry*geometry =
geode.getDrawable(i)-asGeometry();
if (geometry) {
std::string name = geometry-getName();
if (!geometry-areFastPathsUsed())
std::cout name is not using fast path\n;
}
}
}
checkFastPath fptest;
getSceneData()-accept(fptest);
Nothing comes up. I did have an else on this test
(!geometry-areFastPathsUsed()) to make sure that I was hitting the
conditional. I did the same test before quitting and nothing comes up,
neither after initialization nor at the end.
Any ideas? Are there any other roads to the short path?
On Wed, 1 Dec 2010, Keith Parkins wrote:
Hi,
My app is currently rendering via the slow path. I've checked for
DrawArrayLengths and BIND_PER_PRIMITVES, but don't seem to have either. Dose
anyone know of other things I should be looking for? I am walking through
the rendering stage to see if I can figure out what is getting set that is
putting me on the slow track, but I don't have endless amounts of time to do
this. If anyone has any understanding of this, I would be most appreciative
if you could point me in the right direction.
If you need more information, check my post FBO problem?
Thanks!
Keith
PS: Thanks a lot for the help, Jason.
On Tue, 30 Nov 2010, Jason Daly wrote:
On 11/30/2010 08:09 PM, Keith Parkins wrote:
I am using geo-setNormalBinding(osg::Geometry::BIND_OVERALL);
and I did see a model with NormalBinding PER_VERTEX. Should I be setting
these to BIND_OFF or is it just BIND_PER_PRIMITIVE?
No, BIND_PER_PRIMITIVE is the bad binding. All of the others are fine.
If you are avoiding BIND_PER_PRIMITIVE and the attribute indexes, I'm not
sure why you'd be falling off the fast path. There may be other reasons for
it, but I can't think of them...
--J
___
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
___
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
