Curtis Olson wrote:
On 11/7/06, *Ampere K. Hardraade* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Shouldn't there be three? Or is FlightGear not getting inputs from
the user when it hangs?
Well by my count: 1. main thread, 2. scenery paging thread, 3. weather
fetching
On Tuesday 07 November 2006 14:07, Didier Fabert wrote:
hy,
a reason to use OSG is a perf improvement with SMP. but i see nothing about
it here.
my processor (amd 4200 double core) occupation is always 50-55%. perhaps is
it not done yet?
We do not yet make use of that. osg is a techonlogy
hy,
a reason to use OSG is a perf improvement with SMP. but i see nothing about it
here.
my processor (amd 4200 double core) occupation is always 50-55%. perhaps is it
not done yet?
on the other hand, my processor let me use Atlas without reduce fgfs perf.
ps: fgfs is compiled with the
Quoting Didier Fabert :
hy,
a reason to use OSG is a perf improvement with SMP. but i see nothing about
it
here.
my processor (amd 4200 double core) occupation is always 50-55%. perhaps is
it
not done yet?
on the other hand, my processor let me use Atlas without reduce fgfs perf.
ps:
IMHO, full threaded fgfs would be nice at 2.0beta release ;)
On 11/7/06, Curtis Olson [EMAIL PROTECTED] wrote:
On 11/7/06, Frederic Bouvier [EMAIL PROTECTED] wrote:
FGFS doesn't use threading much at that time. Only for the scenery loader
and
metar. One can thing of putting the FDM or AI
Quoting Curtis Olson:
On 11/7/06, Frederic Bouvier [EMAIL PROTECTED] wrote:
FGFS doesn't use threading much at that time. Only for the scenery loader
and
metar. One can thing of putting the FDM or AI in other threads, or maybe
even
divide the viewport into small areas that could be
Le mardi 7 novembre 2006 15:24, Frederic Bouvier a écrit :
Ok, but you have to acknowledge that the trend is to multiply the number of
cores that are possibly less porwerful on their own. Look the frequencies :
2 years ago, you had one core clocked over 3Ghz, now 2 cores are clocked at
about
threading, locking etc ...
- Original Message -
From:
Curtis
Olson
To: FlightGear developers
discussions
Sent: Tuesday, November 07, 2006 9:01
AM
Subject: Re: [Flightgear-devel] OSG and
multicore processor
On 11/7/06, Frederic Bouvier
[EMAIL PROTECTED] wrote
Quoting Peter Gervais :
I've used the ACE programming framework to implement threaded applications in
the past. There are considerable advantages to using such as a framework to
do threading. As well, it also supports message queues which work very well
with threads. It has all the paradigm
Le mardi 7 novembre 2006 16:39, Frederic Bouvier a écrit :
Beware : ACE is bigger than FGFS. OpenSceneGraph comes already with its
threading library : OpenThreads, and FG already use threads with a simpler
one
: pthreads. I don't think we need to jump on another tool. We should first
think
On Tuesday 07 November 2006 16:50, Curtis Olson wrote:
Threads impose a huge penalty in terms of complicating the code, hiding
really subtle bugs, and maintaining threaded code over time just
complicates this matter because new people come in and make changes when
they don't fully understand
On 11/7/06, leee [EMAIL PROTECTED] wrote:
I suspect that the graphics will prove to be the trickiest problem - it's byfar the greatest resource user - Right, in all this we need to remember that in all our past benchmarking, the graphics themselves account for 90-95% of the workload. OSG provides
Curtis Olson writes:
Right, in all this we need to remember that in all our past
benchmarking, the graphics themselves account for 90-95% of
the workload.
I haven't profiled FGFS in a long time however I guess that
is true if you consider ground intersection and database
paging part
Norman Vine schrieb:
Curtis Olson writes:
Right, in all this we need to remember that in all our past
benchmarking, the graphics themselves account for 90-95% of
the workload.
I haven't profiled FGFS in a long time however I guess that
is true if you consider ground intersection and
Hi,
a reason to use OSG is a perf improvement with SMP. but i see nothing about
it
here.
my processor (amd 4200 double core) occupation is always 50-55%. perhaps is
it
not done yet?
No, it is not possible at this time.
Olaf
Selon Olaf Flebbe :
Norman Vine schrieb:
Curtis Olson writes:
Right, in all this we need to remember that in all our past
benchmarking, the graphics themselves account for 90-95% of
the workload.
I haven't profiled FGFS in a long time however I guess that
is true if you consider
Hi,
How are you profiling ?
I had a Intel VTune eval license in the past.
Olaf
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your
Hi,
Curtis Olson wrote:
On 11/7/06, *leee* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I suspect that the graphics will prove to be the trickiest problem
- it's by
far the greatest resource user -
Right, in all this we need to remember that in all our past
i've found here (pentium D 805) :
okay, we lost 3d clouds and some shiny transparencies, but...
the frame rate, although lower, gave me a smoother play. no bigger
drops, like with the plib branch.
in general, it left the impression of a more robust fgfs
just my 3cents
(sorry for the bad
On Tuesday 07 November 2006 20:11, Curtis Olson wrote:
On 11/7/06, leee [EMAIL PROTECTED] wrote:
I suspect that the graphics will prove to be the trickiest problem - it's
by
far the greatest resource user -
Right, in all this we need to remember that in all our past benchmarking,
the
On Tuesday 07 November 2006 10:50, Curtis Olson wrote:
I'm not saying we should not ever do threading in flightgear, indeed we
have two sub threads along with the main program already.
Shouldn't there be three? Or is FlightGear not getting inputs from the user
when it hangs?
My only point is
On Tuesday 07 November 2006 14:50, Durk Talsma wrote:
With the advent of multicore CPU's I have actually been considering the
possibilities of moving parts of the AI code to a separate thread. The
problem with AI isn't so much that it uses huge amounts of CPU time, but
that it needs it (at
On 11/7/06, Ampere K. Hardraade [EMAIL PROTECTED] wrote:
Shouldn't there be three?Or is FlightGear not getting inputs from the userwhen it hangs?Well by my count: 1. main thread, 2. scenery paging thread, 3. weather fetching thread.
My opinions on:Subtle bugs -- these get hidden anyway without the
On Tuesday 07 November 2006 23:20, Curtis Olson wrote:
Really! We should go out of our way to find a workable non-threaded
solution before we add new threads to the code.
One could always break FlightGear into sub-applications and let them
communicate via UDP ports.
Ampere
24 matches
Mail list logo
