Re: [osg-users] Re: Names for different threading models
I really need a 4 core, 2 GPU machine... Don't we all... In my early years working, I was surprised to discover that most of the time, need is a relative term whose meaning is not dependent on your own appraisal of the situation. (If I win the lottery, I'll buy two identical machines and send one your way :-) Drifting OT here, pardon my rambling. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
Robert Osfield wrote: Wow, popular thread... Heheh. Thread. I think if you had a count of the number are intently reading this thread, the count would be very high. I may not have anything to contribute but I am watching with eager anticipation. Sounds very similar to stuff Don Tidrow and I were trying to work out back in March 2003. Of course, we weren't quite as motivated and OSG wasn't where it is today. This thread makes for good reading though. -Paul ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Re: Names for different threading models
Hi Robert,
Are the different threading models the same between windows and linux? I
remember seeing that windows osg (probably producer) didn't support thread
per context before.
Zach
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: Tuesday, February 06, 2007 12:16
To: osg users
Subject: [osg-users] Re: Names for different threading models
Hi All,
On 2/6/07, Robert Osfield [EMAIL PROTECTED] wrote:
1) SingleThreaded - this is an easy one ;-)
2) RenderingThreadPerContext or CullDrawThreadPerContext
3) DrawThreadPerContext
4) CullThreadPerCameraDrawThreadPerContext
Does this make sense given the above? Is an long winded name for
option 4 sensible?
Wow, popular thread...
What I have gone for is:
enum ThreadingModel
{
SingleThreaded,
CullDrawThreadPerContext,
DrawThreadPerContext,
CullThreadPerCameraDrawThreadPerContext,
AutomaticSelection
};
Is there ideal set up of names? If not please ping me with your
suggestions.
I have changed the default ThreadingModel to AutomaticSelection, and this
calls the new method Viewer::suggestThreadingModel() to set the final
threading model used. This method will look at how many CPU cores you have
available and how many windows you have and try to choose the best threading
model to run.
Expect single CPU single window apps to use SingelThreaded, dual core CPU
single window apps to use DrawThreadPerContext, multiple CPU + multiple GPU
= num cores to use the CullThreadPerCameraDrawThreadPerContext, otherwise
CullDrawThreadPerContext or DrawThreadPerContext will be chosen in cases
where you have multiple windows.
The later CullDrawThreadPerContext or DrawThreadPerContext is something
that I have not decided upon yet, CullDrawThreadPerContext will typically
lead to lower frame latency, while DrawThreadPerContext's double buffer will
lead to an extra frames latency but higher chance of hitting vsync. If you
miss vysnc then you'll pay an extra frames latency anyway...
So if there is any chance you are going to miss a frame DrawThreadPerContext
is your man, while CullDrawThreadPerContext is best when you are sure you'll
hit vsync. Right now I've opted for DrawThreadPerContext in the multiple
window case.
You can also set the threading model yourself.
A word of warning. the CullThreadPerCameraDrawThreadPerContext model has
been implemented and in testing I have found deadlocks that I haven't got to
the bottom of yet. I don't have enough cores to properly test it either - I
really need a 4 core, 2 GPU machine...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Re: Names for different threading models
Hi Robert,
Are the different threading models the same between windows and linux? I
remember seeing that windows osg (probably producer) didn't support thread
per context before.
Zach
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: Tuesday, February 06, 2007 12:16
To: osg users
Subject: [osg-users] Re: Names for different threading models
Hi All,
On 2/6/07, Robert Osfield [EMAIL PROTECTED] wrote:
1) SingleThreaded - this is an easy one ;-)
2) RenderingThreadPerContext or CullDrawThreadPerContext
3) DrawThreadPerContext
4) CullThreadPerCameraDrawThreadPerContext
Does this make sense given the above? Is an long winded name for
option 4 sensible?
Wow, popular thread...
What I have gone for is:
enum ThreadingModel
{
SingleThreaded,
CullDrawThreadPerContext,
DrawThreadPerContext,
CullThreadPerCameraDrawThreadPerContext,
AutomaticSelection
};
Is there ideal set up of names? If not please ping me with your
suggestions.
I have changed the default ThreadingModel to AutomaticSelection, and this
calls the new method Viewer::suggestThreadingModel() to set the final
threading model used. This method will look at how many CPU cores you have
available and how many windows you have and try to choose the best threading
model to run.
Expect single CPU single window apps to use SingelThreaded, dual core CPU
single window apps to use DrawThreadPerContext, multiple CPU + multiple GPU
= num cores to use the CullThreadPerCameraDrawThreadPerContext, otherwise
CullDrawThreadPerContext or DrawThreadPerContext will be chosen in cases
where you have multiple windows.
The later CullDrawThreadPerContext or DrawThreadPerContext is something
that I have not decided upon yet, CullDrawThreadPerContext will typically
lead to lower frame latency, while DrawThreadPerContext's double buffer will
lead to an extra frames latency but higher chance of hitting vsync. If you
miss vysnc then you'll pay an extra frames latency anyway...
So if there is any chance you are going to miss a frame DrawThreadPerContext
is your man, while CullDrawThreadPerContext is best when you are sure you'll
hit vsync. Right now I've opted for DrawThreadPerContext in the multiple
window case.
You can also set the threading model yourself.
A word of warning. the CullThreadPerCameraDrawThreadPerContext model has
been implemented and in testing I have found deadlocks that I haven't got to
the bottom of yet. I don't have enough cores to properly test it either - I
really need a 4 core, 2 GPU machine...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
Hi Zach, On 2/6/07, Zach Deedler [EMAIL PROTECTED] wrote: Are the different threading models the same between windows and linux? I remember seeing that windows osg (probably producer) didn't support thread per context before. All threading models are available on all platforms. In osgViewer threading is entirely orthogonal to windowing, as long the base GraphicsWindow class provides all the makeCurrent/releaseContext/swapBuffers etc that are required everything else should work just fine. Andre's done a good job with GraphicsWindowWin32 so pretty well all the boxes and ticked and has ensured that multi-thread, multi-graphics windows works. Getting things to work multi-thread also required fixes to the core OSG unrelated to windowing, these were static data structure.initialization issues. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
I think if you had a count of the number are intently reading this thread, the count would be very high. I may not have anything to contribute but I am watching with eager anticipation. Ditto ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
