Hi Robert,
One other thing
apparently was a factor in fixing the hitching problem I was having. I had
to generate the database with larger tiles. I used to have a checkerboard
database of tiles, and each tile had about 4 paged files in it. If I
condense those 4 paged tiles into one large one, then I get better
results. Here is the investigation:
INVESTIGATION
-
527 paged files in flat heirarchy, 1GB total, OSG_DO_PRE_COMPILE=OFF: still get some hitching, and paging thread is still working after one AnimationPath loop.
-
153 paged files in flat heirarchy, 1GB total, OSG_DO_PRE_COMPILE=OFF: hitching gone, and paging thread goes to 0% processor after one AnimationPath loop.
QUESTIONS
-
Does this make any sense? It is the same database stored in different amounts of files.
-
Do you think the problem may be that more thread locks are happening when there are more files?
Thanks. Even though
I have a fix for the problem, I'd like to be able to understand it, so I can
avoid it in the future. Also, I'd like to get back to using display lists
if possible.
Zach
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: Tuesday, August 22, 2006 16:40
To: osg users
Subject: Re: [osg-users] Paging performance on Windows
On 8/22/06, Zach
Deedler <[EMAIL PROTECTED]> wrote:
The OSG attempts to reuse both textures and display lists. Where it can't reuse it has to create new ones, and in the case of texture I've found this is significant hit, but display list creation I have to be pretty quick, quicker than reuse paradoxically.
What I have found real slow is the deletion of display lists, so even though display list reuse isn't that efficient avoiding delete gains you some. In the testing I did it seemed a bit of black art, sometimes delete's, create's and reuse would be cheap and other times it wouldn't be. This isn't too suprising considering the rather disonnected way that you interact with the actual graphics hardware, the fifo is typically your friend but sometimes it can fill and bite your butt.
That all being said, 5 seconds is a very very long time for compile, delete or reuse of most comonly sized objects, typically you'll have to try to handle an object of several million vertices to see this type of hit. No doubt you arn't hitting this limit with your objects as your paging them, so my guess is that the driver and OS are getting their knickers in a twist handling all the data allocation, coping and deletion.
The DatabasePager does try to minimize these problems, in fact most of the code in the DatabasePager is all about load balancing to prevent these problems, however, it can't solve all the problems, the OS, OpenGL driver, memory and database makeup all have a roll to play in keeping things work well.
Perhaps the OS is using virtual memory and paging out things like geometry, display lists and texture objects to disk, and if the file system is a file of horse dung then the hit could be pretty big. 5 second still seems severe though. It'd be worth trying out the database on a machine with more memory to see if it helps, if only to prove that its not swap space hitting you.
Not using display lists is another possible route, or using them selectively. Use vertex arrays is the slowest performance wise, but if you don't have too much geometry it might not be too much of hit, and you don't need to worry about the hit on creating, compiling and deleting display lists. You have already come across the options in the DatabasePager for overriding the display lists/VBO options so I needn't add much here. To do things selectively you'll have to set up the flags for display lists/VBO's in the .ive file itself.
Oh from my experience don't even try VBO's for paging, the hit right now is way to high in trying to create, reuse and delete them.
Robert.
Hi Chris,
I can look at the OpenFlight database, but we did not make it so I'm not
sure off the top of my head. Can you define heavy? A lot of vertices? A
lot of textures? A lot of objects, polygons, groups? Can it really take 5
seconds to compile a displaylist?
I'm still investigating.
The OSG attempts to reuse both textures and display lists. Where it can't reuse it has to create new ones, and in the case of texture I've found this is significant hit, but display list creation I have to be pretty quick, quicker than reuse paradoxically.
What I have found real slow is the deletion of display lists, so even though display list reuse isn't that efficient avoiding delete gains you some. In the testing I did it seemed a bit of black art, sometimes delete's, create's and reuse would be cheap and other times it wouldn't be. This isn't too suprising considering the rather disonnected way that you interact with the actual graphics hardware, the fifo is typically your friend but sometimes it can fill and bite your butt.
That all being said, 5 seconds is a very very long time for compile, delete or reuse of most comonly sized objects, typically you'll have to try to handle an object of several million vertices to see this type of hit. No doubt you arn't hitting this limit with your objects as your paging them, so my guess is that the driver and OS are getting their knickers in a twist handling all the data allocation, coping and deletion.
The DatabasePager does try to minimize these problems, in fact most of the code in the DatabasePager is all about load balancing to prevent these problems, however, it can't solve all the problems, the OS, OpenGL driver, memory and database makeup all have a roll to play in keeping things work well.
Perhaps the OS is using virtual memory and paging out things like geometry, display lists and texture objects to disk, and if the file system is a file of horse dung then the hit could be pretty big. 5 second still seems severe though. It'd be worth trying out the database on a machine with more memory to see if it helps, if only to prove that its not swap space hitting you.
Not using display lists is another possible route, or using them selectively. Use vertex arrays is the slowest performance wise, but if you don't have too much geometry it might not be too much of hit, and you don't need to worry about the hit on creating, compiling and deleting display lists. You have already come across the options in the DatabasePager for overriding the display lists/VBO options so I needn't add much here. To do things selectively you'll have to set up the flags for display lists/VBO's in the .ive file itself.
Oh from my experience don't even try VBO's for paging, the hit right now is way to high in trying to create, reuse and delete them.
Robert.
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
