> you are doing yourself a ***HUGE*** favor if you keep all the opengl
> calls caged in a single thread.
OK, this is obvious. I obviously misinterpreted the original statement:
Threading *within* *an* OpenGL context. I wanted to point out that
threading goes well with OpenGL as long as all OpenG
On Wednesday, July 2, 2003, at 01:00 PM,
[EMAIL PROTECTED] wrote:
Message: 3
Date: 2 Jul 2003 16:30:37 GMT
From: Martin Spott <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] Again: Threaded FlightGear ?
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
"Curtis
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> An analogy would be following directions from city A to city B. You
> are fed a seqence of commands "turn left", "turn right", "go
> straight", etc. If you follow these commands in the exact sequence
> you recieve them, you will end up at the correc
Gerhard Wesp writes:
> > I know that threading inside an OpenGL context is considered to be a no-no,
>
> Why?
You can think of OpenGL as a "state machine". The sequence of calls
you feed into it determines the path that the state machine takes.
And that determines what get's rendered.
An analog
Gerhard Wesp writes:
>
> > I know that threading inside an OpenGL context is considered to be a no-no,
>
> Why? References?
http://www.opengl.org/developers/documentation/specs.html
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.f
> I know that threading inside an OpenGL context is considered to be a no-no,
Why? References?
A problem I see is that threading isn't implemented in a standard
compliant way on Linux (probably one of the more important platforms),
but maybe one can work around that problem.
-Gerhard
--
| voic
Norman Vine wrote:
Norman Vine wrote:
Ummm.
<533> math
$ c++ -O3 -o test test.cxx fastmath.cxx
Ooops pardon the line noise
Pfew, you scared me :-D
I didn't reinitialize the clock in my test program
Here are the updated test results
*NICE* win on the log() call
And quite accurate
Norman Vine wrote:
>
> Ummm.
>
> <533> math
> $ c++ -O3 -o test test.cxx fastmath.cxx
Ooops pardon the line noise
I didn't reinitialize the clock in my test program
Here are the updated test results
*NICE* win on the log() call
<537> math
$ ./test
log3014
fast_log 120
ex
Erik Hofman writes:
>
> Yes, I mean 250% increase. But I doubt many others would see such an
> increase because my framerates were already close to freezing point...
Ummm.
<533> math
$ c++ -O3 -o test test.cxx fastmath.cxx
<534> math
$ ./test
log3044
fast_log 3164
exp7150
Nice box
On Sat, 2003-06-28 at 11:00, Erik Hofman wrote:
> Christopher S Horler wrote:
> > So what frame rate are you actually getting and on what hardware?
>
> If you promise not to laugh at me:
>
> 3~4 fps on a sgi O2 (default Cessna, I get 7~10 fps when selecting
> models without 3D panel).
Christopher S Horler wrote:
So what frame rate are you actually getting and on what hardware?
If you promise not to laugh at me:
3~4 fps on a sgi O2 (default Cessna, I get 7~10 fps when selecting
models without 3D panel).
Erik
___
Flightgear-devel mai
So what frame rate are you actually getting and on what hardware?
On Sat, 2003-06-28 at 09:23, Erik Hofman wrote:
> Christopher S Horler wrote:
> > Erik,
> >
> > Can you confirm exactly what you mean - 2.5x existing frame rate?
>
> Yes, I mean 250% increase. But I doubt many others would see suc
Christopher S Horler wrote:
Erik,
Can you confirm exactly what you mean - 2.5x existing frame rate?
Yes, I mean 250% increase. But I doubt many others would see such an
increase because my framerates were already close to freezing point...
Erik
___
Fl
Erik,
Can you confirm exactly what you mean - 2.5x existing frame rate?
Thanks,
Chris.
On Fri, 2003-06-27 at 22:39, Erik Hofman wrote:
> Norman Vine wrote:
>
> > Hmm
> > [40] 24.060 1.7% 29.3% 61.140 4.3% 2038 __powf (libm.so:
> > fpow.c, 145)
> > [96] 19
Norman Vine wrote:
Hmm
[40] 24.060 1.7% 29.3% 61.140 4.3% 2038 __powf (libm.so:
fpow.c, 145)
[96] 19.500 1.4% 35.3% 19.500 1.4%650 __exp (libm.so:
exp.c, 103)
[102] 17.460 1.2% 37.8% 17.460 1.2%582 __log (libm.so:
Erik Hofman writes:
>
> Norman Vine wrote:
>
> >>>http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz
> >
> >
> > You have to let the process run much longer
> > until things like ssgMakeMipMaps don't show up in the top 100 :-)
>
> There is a new file after running FlightGear for about
Martin Spott <[EMAIL PROTECTED]> wrote:
> I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
> FlightGear on this machine. This won't work out as long as most of the
> processing in FlightGear is done in a single thread because each of the
> CPU's is not that fast.
O.k., I
On 24 Jun 2003 16:32:17 GMT,
Martin Spott <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> Martin Spott <[EMAIL PROTECTED]> wrote:
>
> > Sincerely there are more urgent jobs to do - enabling flying below
> > bridges or through the Sutro tower, for instance ;-))
>
> I have to correc
Norman Vine wrote:
http://www.a1.nl/~ehofman/fgfs/download/usertime.output.gz
You have to let the process run much longer
until things like ssgMakeMipMaps don't show up in the top 100 :-)
There is a new file after running FlightGear for about 23 minutes.
Erik
__
Norman Vine wrote:
You have to let the process run much longer
until things like ssgMakeMipMaps don't show up in the top 100 :-)
The nice thing is that it also contains OpneGL calls.
That is good and bad
the bad part is that it takes time to instrument the profiling
and since we can't do anything
On Tue, 24 Jun 2003, Curtis L. Olson wrote:
> Lawrence Manning writes:
> > Well, with threads you can spread the load across CPUs. So it is not
> > just a convience for the programmer. Afterall, the original poster
> > bought up the matter of big boxes with lots of slow processors.
>
> Right, b
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
> I don't want to add a bunch of threads if the only reason is that
> threads looked cool and fun when we studied them in a computer science
> class, and there is one person with a machine that could benefit.
I think I have to give further explanation
Curtis L. Olson writes:
>
> Erik Hofman writes:
> > Curtis L. Olson wrote:
> >
> > > True ... what I was trying to communicate is that if something like a
> > > property string fetch shows up high in list of time consuming function
> > > calls, we don't necessarily know if most of those calls wer
Erik Hofman wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like
to run
FlightGear on this machine. This won't work out a
Things that come in mind are:
* Sound thread (should be fairly easy)
* FDM thread/process
* Maybe (just maybe) an I/O thread?
Hmm, either an I/O th
Erik Hofman writes:
> Curtis L. Olson wrote:
>
> > Did anyone say if this multi-cpu machine had an accelerated opengl
> > graphics system? If it doesn't then this whole discussion is
> > pointless. :-)
>
> Maybe not, threaded MESA?
Good luck. :-) If someone could get fast rendering speeds via t
Curtis L. Olson wrote:
Did anyone say if this multi-cpu machine had an accelerated opengl
graphics system? If it doesn't then this whole discussion is
pointless. :-)
Maybe not, threaded MESA?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
ht
Erik Hofman writes:
> Curtis L. Olson wrote:
>
> > True ... what I was trying to communicate is that if something like a
> > property string fetch shows up high in list of time consuming function
> > calls, we don't necessarily know if most of those calls were made
> > during initialization where
Lawrence Manning writes:
> Well, with threads you can spread the load across CPUs. So it is not just
> a convience for the programmer. Afterall, the original poster bought up
> the matter of big boxes with lots of slow processors.
Right, but we should also bear in mind the a) "typical" flightgea
Martin Spott <[EMAIL PROTECTED]> wrote:
> Sincerely there are more urgent jobs to do - enabling flying below bridges
> or through the Sutro tower, for instance ;-))
I have to correct this statement: It _is_ possible to fly through the Sutro
tower, but it's not that easy to view from inside the c
Curtis L. Olson wrote:
True ... what I was trying to communicate is that if something like a
property string fetch shows up high in list of time consuming function
calls, we don't necessarily know if most of those calls were made
during initialization where it doesn't really matter, or during the
Norman Vine writes:
> Note fgUpdateTimeDepCalcs() and fgMainLoop() are *only* called after
> all initialization is done, so if anything, they actually consumed a bit more
> then their recorded usage time whereas fgRenderFrame is the opposite :-)
True ... what I was trying to communicate is that
Curtis L. Olson writes:
>
> Norman Vine writes:
> > Curtis L. Olson writes:
> > >
> > > Think about this another way ... do a profile of flightgear. I bet
> > > you will find that the graphics rendering portion of FlightGear takes
> > > 90-95% of the entire application work load.
> >
> > FWIW
Martin Spott writes:
> This was my initial thought when I bought an SGI Octane with bells 'n
> whistles. But I was proven to be wrong. Erik's O2 is definitely faster with
> FlightGear even though the O2's graphics subsystem is much slower. This is
> hardly texture-related, his machine simply has th
Norman Vine writes:
> Curtis L. Olson writes:
> >
> > Think about this another way ... do a profile of flightgear. I bet
> > you will find that the graphics rendering portion of FlightGear takes
> > 90-95% of the entire application work load.
>
> FWIW here are my results from the last time I p
Lawrence Manning <[EMAIL PROTECTED]> wrote:
> It would be interesting to profile fg and determine exactly where the time
> is spent. I'd guess that even a low spec machince could handle the
> "simulation" aspects of the program; is it not the the rendering that
> consumes the majority of the p
Lawrence Manning writes:
>
> It would be interesting to do some tests in wireframe mode on a low spec
> machine and see how it performs?
I think you wil find that wireframe mode is slower
esp if you turn off the cloud textures
Norman
___
Flightgear-
Curtis L. Olson writes:
>
> Think about this another way ... do a profile of flightgear. I bet
> you will find that the graphics rendering portion of FlightGear takes
> 90-95% of the entire application work load.
FWIW here are my results from the last time I profiled FGFS trying
to determine w
Bernie Bright wrote:
For the record, the top 20 functions as reported by oprofile-0.5.3 are:
The problem is that (as Norman pointed out in the past) optimizing may
result in a much larger increas in framerate due to the way OpenGL can
handle processor and graphics tasks simulataniously.
Cpu typ
On Tue, 24 Jun 2003, Curtis L. Olson wrote:
> > I'm not quite sure how threads can help, except possibly with the
> > simulation of hundreds of aircraft at once?
>
> In the case of simulating 100's of aircraft, threads might provide a
> convenient programming abstraction, but they would add the o
On Tue, 24 Jun 2003 07:46:39 -0500
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:
[snip]
> Think about this another way ... do a profile of flightgear. I bet
> you will find that the graphics rendering portion of FlightGear takes
> 90-95% of the entire application work load. If you can't find a
Lawrence Manning writes:
> Dunno if this is valid, but here's my thoughts.
>
> It would be interesting to profile fg and determine exactly where the time
> is spent. I'd guess that even a low spec machince could handle the
> "simulation" aspects of the program; is it not the the rendering that
On Tue, 24 Jun 2003, Erik Hofman wrote:
> Martin Spott wrote:
> > I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
> > FlightGear on this machine. This won't work out as long as most of the
> > processing in FlightGear is done in a single thread because each of the
> > C
Curtis L. Olson wrote:
Erik Hofman writes:
* Sound thread (should be fairly easy)
* FDM thread/process
* Maybe (just maybe) an I/O thread?
But I guess that's about it.
>
Personally, I'm not a huge fan of threading unless absolutely
necessary. Threading adds a tremendous amount of complexity, i
Erik Hofman writes:
> Martin Spott wrote:
> > I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
> > FlightGear on this machine. This won't work out as long as most of the
> > processing in FlightGear is done in a single thread because each of the
> > CPU's is not that fast
> Martin Spott wrote:
> > I'm about to purchase a used 8-way RS/6000. Coltish as I am
> I'd like to run
> > FlightGear on this machine. This won't work out as long as
> most of the
> > processing in FlightGear is done in a single thread because
> each of the
> > CPU's is not that fast.
>
> Thin
Martin Spott wrote:
I'm about to purchase a used 8-way RS/6000. Coltish as I am I'd like to run
FlightGear on this machine. This won't work out as long as most of the
processing in FlightGear is done in a single thread because each of the
CPU's is not that fast.
Things that come in mind are:
* So
46 matches
Mail list logo