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 OpenGL
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
--
|
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 analogy
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 correctly place.
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 L. Olson [EMAIL PROTECTED
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
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
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
exp
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
___
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 such an
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
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).
Erik
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
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 23 minutes.
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:
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.
As Curt is moving lots of code around to make
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:
*
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
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.
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,
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
CPU's is
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 way
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
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
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
___
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
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 profiled
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 the
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 here are my
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 if
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
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
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 flightgear
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 it
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]
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
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 were made
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, but we
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
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
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 correct this
41 matches
Mail list logo
